I have a fairly complex express based web application that is split up into a few sub apps which are also express apps (using app.use()). How can I seamlessly use the same session between all parts of the app?
the middleware bundled with Connect are "self aware" in that they will not duplicate work they've already done. So for example if you have req.session already, and both the "root" app, and a mounted app utilize the session() middleware, the root app's session will work, and the other will be ignored. So it should work as-is.
Related
I have a single-page react application, let's call it foo, bundled with webpack, that I am serving statically with Express.js. I need to share a session from another application which is launching foo. I am thinking of generating a JSON web token and POSTing to the Express server with the token in the Authorization header.
Currently I pass information from the launch request into the application by setting a cookie with Express and reading the cookie in the application. However I predict there are security flaws with this approach (JWT.io indicates "You also should not store sensitive session data in browser storage due to lack of security."). I don't know how else to pass information to foo, since it's not actually an express.js app, it's more like a cross-platform JS app that is now being hosted. So since it is served statically I do not invoke any 'startup' actions from express.
I can see a couple angles towards a solution, but I am not sure which to take.
Can I expose the request headers to the static react app so that it can securely be read?
Can I serve the webpack bundle 'non-statically' (dynamically?) from express, and invoke a startup function?
I have been working with express-session for a long time with mongodb as session store , so now I got the chance to work with frontend framework which is angular 2 and I was wondering how to maintain session across frontend and server as both are running on different ports
So for person working on express-session is there any way to use that with angular or do I have to move to JWT
In future I would have to integrate socketIO as well to the project, So what is the right way to go about this
You can handle sessions with Angular 2+ the same way you would with any other web site. In fact, using Express Session is all you need to do, as session management is handled automatically by the browser.
Feathers auth provides only JWT authentication, even if strategy is local.
Should I make full custom middleware for express-session usage and clean passport implimentation just to achive regular sessions behaviour or there's some solutions for this purpose?
Also, I want to use passport.socketio for autheticate sockets aswell.
Using Feathers authentication module is entirely optional and you can always register your own middleware at any point like before and after a service. This means you can set up a normal Express session setup and then set req.feathers to the information from the session that you also want to pass to Feathers services (like the user). As you mentioned, you will have to do the same thing with websockets (which also allow setting handshake.feathers in its middleware).
A full tutorial how to set up sessions and using authentication can be found in the Using A View engine cookbook documentation.
I have a node application that's using passport-local-mongoose for authentication. I have a second node app that's served in an iframe of the first app. I'd like to protect the express routes in the second app with the same session of the first app so that the user only logs in once, but the express routes in the second app are still protected. Is there a way for the two node apps to share a session? Or perhaps there is another approach?
Thank you.
The easiest way I can think of would be to simply store sessions in MongoDB. Then your second app's middleware could check the session passed in the request against the same database. The downside of this approach is that you have to implement some of the same authentication logic in 2 places.
Perhaps even better, you could build a 3rd microservice that handles authentication specifically. That would basically wrap your session store and centralize the authentication logic in one place. Both of the other 2 apps would then consume this service. This is an area I'm still learning about personally, and this site has been helpful: https://dejanglozic.com/2014/10/07/sharing-micro-service-authentication-using-nginx-passport-and-redis/.
I'm investigating using Stormpath for our user Management.
I currently have a Sails.js application which uses Node.js / Express.js. Currently, session management is handled by the default Sails.js framework, which relies heavily on Express' session middleware.
Sessions are stored in a shared Redis database on production so that we can keep our multiple API servers stateless.
My question is will the two session management systems conflict and/or cause bugs? Do they have to be consolidated or can we safely keep them separate? if they have to be combined, how do you configure the middleware?
As a note we won't be storing much user data on Stormpath, we'll only be using them as a auth/token provider.
Thanks for the help!
I'm the author of the express-stormpath library, which is what I'm assuming you're evaluating.
You can indeed use your own sessions in addition to the stormpath ones. The way it works is like so:
Stormpath uses req.session to store a stormpathSession cookie. Any other cookies you create / store, will be handled by you completely.
It should work nicely with whatever session library you choose =)