My web application production deployment is on 2 servers behind a load-balancer.
I'm using passport (local strategy) with session for authentication.
When the application runs on one server everything works fine, but in production one server doesn't recognize the cookie/session established by the other server (Each request gets randomally sent to a different server, I can't control it).
As a result - i'm redirected to the login page when attempting to access pages that require authentication (even after i login).
How can i get the two servers to create a session cookie that they both recognize (obviously i used the same secret for the express session middleware).
Thanks,
Alon
Option 1
Configure the load-balancer to always route the same ip to the same machine. Might be problematic for users who change network.
Option two
Use a third machine running the database and set up express.session (and any other database connections for that matter) to use that machine as store. This question/answer mentions how to do it with mongoose/mongodb.
I think this is the more common solution but is of course more expensive if you don't need a third machine.
Related
I'm new to whole authentication/authorization part in web development. Specifically JWT. So I came across a medium post explaining the fundamentals of JWT. There was a diagram which showed how the web server and authentication server had no direct communication, AFTER a JWT token had been issued by the authentication server.
So, my 3 questions are:
What's the difference between the authentication server and the web server?
Is the authentication server, the database server?
And, since you are going to take user data(e.g password/username) from the
client(browser/user), to which server do you write the code to? authentication or web?
Because NodeJS/Express allows you to write the app server code right?
1 - An auth server is usually part of a microservice architecture, if you do not have to scale you can have a simple authentification middleware in your web server.
2 - The auth server is a server usually part of a microservice architecture which role is to authentificate requests and act as a gateway to the rest of the microservices.
3 - Depends if you want to scale or not. If you want to separate auth and the rest of the apis, there are multiple ways to scale.
Hope it helps =)
What's the difference between the authentication server and the web server?
These are two separate servers. Two different programs, potentially running on two (or more) different machines. With different purposes and responsibilities.
Is the authentication server, the database server?
No. For all you know the auth server may not use db at all. For example it can store all the data directly in files, or even in memory. Although, in practice there will be some db behind it. Auth server is just a server with a special purpose: user authentication (as the name suggests).
And, since you are going to take user data(e.g password/username) from the client(browser/user), to which server do you write the code to? authentication or web? Because NodeJS/Express allows you to write the app server code right?
Write code? Both? Depends on whether you implement the auth server by yourself or not. I'm not sure I get that question.
The point is that user credentials should be send to the auth server and the auth server is responsible for validation, secure storage and token issuing. So that other servers (in particular the one you call "web") don't have to worry about it.
My collegues and I want to build a chat application (ReactJS <-> NodeJS), and we have been looking for the best framework to do so. FeathersJS seems undoubtedly the most stable and feature-rich socket.io wrapper.
However, as we want to allow our application to scale up, we have decided to split this chat feature in a different node process than our main node backend.
The chat functionalities still requires authentication and authorization however, and we would like to avoid duplicating authentication for the two services. Hence what we have come with as a solution is to query the main node backend with the session cookie to authenticate the user before letting them use the chat service.
Does FeathersJS establishes long-lasting socket connections or would it establish a socket connection for every message sent/received? In the first case we could proceed with our architecture, whereas on the second we'd have to review due to the high load this would produce on the main backend.
Thanks!
There are several ways of splitting up services each with their own advantages and drawbacks. One generally important thing for Feathers is that there are no sessions, just JSON web tokens. JWTs are stateless and can be read by any server that shares the same secret so there does not have to be a central session store. The two main options I can think of are:
Have a main application that handles authorization and managing all connected clients but instead of having services that talk to the database they connect to separate simple individual API servers in the internal network. This is the easier setup and the advantage is that the internal API servers can be super simple and don't need authentication at all (since the main application is allowed to do everything and will make queries according to the authenticated users restrictions). The disadvantage is that the main application is still the bottleneck (but with a decreased load since it basically acts as a proxy to internal APIs).
Every client connects to every API server they need using a JWT. The JWT is created by a separate authentication (or user) API. This is the more scalable solution since the only bottleneck is retrieving the most up-to-date user information from a common users service (which might not even always be necessary). The disadvantage is that it is more complex to manage on the client side and authentication (at least for JWT) will have to be configured on every server. Due to the statelessness of JWT however, there does not need to be any shared sessions.
I find myself in a bit of a dilemma. I am preparing to push code out to a test server (out in the wilds of the Internet) which handles user registration and authentication (using Express + Passport) for acceptance testing.
However, I would like to be able to restrict access to the test server to those users who will be performing testing. I know node does not support an .htpasswd file mechanism but looking for another way to restrict users from accessing the server even before the application authentication process begins.
All thoughts welcome!
You can restrict via IP address in your application, or the server's firewall. If you have a reverse proxy like nginx in front of node, then you can set it up to require basic authentication via an htpasswd-like file.
I have deployed my asp.net MVC application in a Azure environment behind load balancer. Same web application (simila files) are deployed in two Azure VMs' (cloned VMs). Deployments are identical.
Business logic
Session userID is stored in the cookie (created upon sign in), therefore if the server cannot read the cookie it is directed to sign out.
Issue is that when I send a sign in request from browser, lets say it hits Server A and then it sign in successfully. After few requests, once I hit the Server B directed by the load balancer, it signs out. Similar thing happens if I sign in with server B, then I sign out once I hit server A.
Both servers can be accessed as http and https. I tried with http and https modes, issue exists in both the modes.
I replaced the Server B machine configs (both Framework and Framework64) with machine configs of Server A.
I am still getting the issue.
Here is my configuration,
<authentication mode="Forms">
<forms cookieless="UseCookies" defaultUrl="~/Home" loginUrl="~/user/signin" domain=".mydomain.net" name="FormAuthentication" path="/"/>
</authentication>
<machineKey validationKey="XXXXXXXXXX7E8095B292DFC0984B71212747191E878380CADAA8166B0D9C8E8E7B174AF38897E28F82DXXXXXXXXXXCB0CF7ABA161AAC6D86EDBCAA93704EE7FC" decryptionKey="XXXXXXXXXXDE9EA41A2423A2CD293C01050202746F5650E7" validation="SHA1" compatibilityMode="Framework20SP1"/>
More info - Servers are named like server1.cloudapplicaiton.net, server2.cloudapplicaiton.net. Application domain is like mydomain.net.
Also, I programatically set the cookie name as "mydomain.net" upon Firmsauthentication sign in.
Am I missing something? Why can't a server read the cookie created by another server which has the same machine key and domain?
I have few ideas where im not sure if Im correct and if my approach is correct.
The situation is that I got some backend server(s) which exposes REST (of course stateless) interface and expects usage of HTTP authentication via its headers. Then I have some its clients and one of them is web server which has loaded web application that is accessed by typical web browser (using SSL). User via web browser enters his credentials (username and password), which are sent to web server and here comes the thing I want to ask. Web server will delegate all the requests to backend server (REST) putting those credentials to HTTP headers. Is it safe to store those credentials within HTTP session between web server and browser? And if not, where to store them otherwise?
Thanks:-)
for as long as you using session.abandon at the end of the session(application exit or close) all your data should be in theory safe.
Make sure that you close session when application shuts down or user idle for too long.
I usually give no more then 20 minutes. Over HTTPS even less.