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/.
Related
I'm building a next.js project and while I usually would just use the "Custom Express Server" method to implement my graphql API (using apollo-server-express), I thought that it might be a good idea if I decoupled the next.js project from the graphql API so that each of the servers are hosted on different machines.
But usually I would implement any session-related logic in the graphql API, using something like graphql-passport; I figured that's good practice because if I ever choose to add another frontend (maybe a mobile app or something) they can share the same session logic. But given that I'm server side rendering content with next.js, how do I forward the user's session info to the graphql server? Because the next.js server shouldn't have to redo authentication, right?
Let me know if there are any flaws in the architecture too, I'm kind of new to this.
Using the Next server to run the GraphQL service is certainly not a good idea, so yes, do separate the two.
Letting the Next server SSR-render pages with user specific content using the users session is probably not a good idea either, unless you have some specific use case that requires the served HTML pages to have the user specific data in them already. The reasons for this are:
SSR rendering will require lots of server side computations since all pages always will have to be rerendered.
NextJS is moving away (since v9.3) from the getInitialPros() way of doing things towards using getStaticProps() to generate a page that is common for all users and which can load its session dependent stuff straight from the GraphQL API once it is displayed on the client device.
This approach will generally have higher performance and scale much better.
Should you really want to go the "SSR with user session data" route you start in the getServerSideProps(context) method, where context.req is the actual request which will have all your session data in it (cookies or headers).
This session data you can then extract from the req and pass on to the GraphQL server requests that require authentication.
I have a question.
I am using express 4 and to host my services and my client (angular pages).
I want to add Redis middleware in order to cache response of requests.
I know there are modules which cache request according to user session
but my situation is a bit different.
Because I want to cache result of all the requests from specific tenant.
one tenant can have multiple users,
In my authentication process I can find out if the specific request belong to the same tenant or not.
As already figured out I have multi-tenant application
Any suggestions how to approach this problem ?
A bit tardy, but you can check module express-redis-cache (disclosure, I am the author). It should allow you enough flexibility.
I'm using angular with socket.io and express on the backend (redis/mongodb).
What's the easiest way to validate a user's password and log them into my app?
I haven't written any code for to handle this yet. but I keep seeing 10 different ways, some using sessions (which I think don't apply here since sockets+singlepage app).
If passport.js is easy to implement I'm fine with that solution. I only care about IE9+
I have two different applications running on the same server, one is Java-based running in Tomcat with spring-social and spring-security, and the other is a NodeJS application using PassportJS as security framework.
Both apps are configured to access using Google OAuth2 with the same clientId/secret, so I can login with my google account in each of them. But if I change from one of them to another, I need to login again, because the session doesn't exist on the other app.
I'm looking at the session cookies, the Java app creates the JSESSIONID cookie whereas the Node app creates a "connect.sid" cookie. Maybe I could create a session in each app everytime a user do a login? Or I have to deal with OAuth tokens?
Please, could you point me in the right direction? Should I use another library/framework?
Thank you in advance.
This might be of help; it looks like it's relatively easy to change the name of the cookie for Express/Connect. The question then just becomes whether the contents of JSESSIONID and connect.sid are in fact the same.
I'm currently searching the best way for developing my next webapplication. I'm thinking about using Backbone.js and build a single page application. But I really can't imagine how to secure my app since nearly everything is done on client side. Of course I just could prevent the users from accessing my RESTful Api so they would not have access to my data. But all the view/model/collection/template js files are still accessible.
Or is there a known way to serve the js files with php (laravel), which would allow me to only serve the files I need for the respective user.
I just couldn't find a solution by searching the Web. But I just don't think that I am the lonely person who needs a clean and secure authentication method including different user rights.
Thank you in advance!
Your backend application will fetch data from a backend (= API), and probably send back some changes.
This code can't have "security holes / leaks" as long as your backend is secured.
If you are afraid of people stealing your code, you can always minify the JS (check grunt.js and almond.js for this)
To secure your backend you can make use of Laravel's auth class, and the auth filter as mentioned before.
Besides normal auth, you could implement roles, that you can assign to specific users, giving them more or less access to certain resources in your backend.
Here's the method I would try :
Separate the application in two parts.
One part - login via regular Laravel Auth on a separate page, and then when the user is logged in serve the single page app in a different view.
Wouldn't this work?
Web Services are no different than any other web application you build. At the end of the day you are exposing functionality to the client (which is also the attacker). It doesn't matter what the client is implemented in, if you expose dangerous functionality you will be hacked.
Have a session state, keep track of the user id and make sure that the user is only accessing resources they have been allowed to access.
I do not think that what JS/template files are exposed really matters. Essentially, you should only be allowing data interaction to authenticated users. Think of this as two separate applications.
The front-end application logs in, and a cookie is stored (or some other persistence is used).
The back-end application then uses the persistent authentication to validate every single user request for data, and every user action.
This way you don't have to worry about the security, the client can only fetch the data that the server allows it to, and, likewise, it can only interact with the data insofar as the server allows it. You shouldn't be relying on the client side for security anyway, even logged in, otherwise some malicious user could, conceivably, save all your frontend code and use it against you without authentication.