Sorry, I don't know the best terminology to do what I am wanting to do.
I have several microservices that share a session secret. Once in a while, the session secret changes, and I will want to "refresh" the microservices with a new session secret.
In the case where, say, two of the microservices get the new secret but one of them doesn't, if the session cookie is signed with a new secret that the microservice does not have, then I can see the session cookie, but sessionID is not populated. This is how I determine if I need to refresh the session secret. So the microservice is able to grab the new secret and add it to the array of session secrets that was passed to express-session during initialization.
However, I was hoping that after this I could try to get the session again using the ID in the session cookie, and return the authenticated page to the user. The problem is, at this point express-session has already done its work, and there is no session present due to the fact that the ms saw a seemingly invalid signature. Currently my solution is to redirect back to the page after session secret is refreshed:
res.redirect(req.originalUrl)
This seems to be working, but is less than ideal. I was wondering if there is some way to tell express to go back to square 1, where it gets a session ID and verifies the signature, and then populates the session if it is present, without a redirect or anything, and once that is done continue to go through all the middleware as if this was a new request.
Any help would be appreciated
Related
I want to do only cookie based authentication for my app. No pwd or email need to be given.
It is like the guest user feature in some webapps (like discord). You can use the app like
a logged in user as long as you have that cookie (or local storage). I find this very seamless and I don't want to put up signup barrier to the visitors.
I want a middleware, which does the following :
If request does not have a session id, it has to create a new session (by adding new document in sessions collection in mongodb, and setting the field session_id with random string)
If the request has cookie, it has to parse the cookie and set in request object. Even better, it gets the session object from db and set it in request object.
Is there anything right out of the box that does this? Or any other ways to easily achieve this?
express-session with a mongodb data store will do that pretty much right out of the box. There are multiple session store options for mongodb here. One of them is even maintained by the mongodb team.
In a nutshell, express-session will check for an incoming session cookie. If one exists, it will look up the session ID in the session store and find the session object for that ID. If there is no cookie or the DB has no session for that ID, it will make sure there's a cookie and create a new session for it. That session will be available as req.session for that request for all request handlers and middleware downstream of the session middleware.
You will need to age away old sessions from mongodb because if you're not attaching any login to them, then lots of the sessions will get permanently orphaned either when the user never comes back to your site or when the user's cookie ages away. And, the same user from multiple devices will cause multiple separate sessions to be created (which is a by-product of the auto-session-creation and login-free design).
I have a question about Sessions and Cookies on Node regarding where they are stored and how they work.
To begin with, I understand the following to be true:
With a cookie, it is possible to specify how long it will store your data;
A session saves data while the browser is open;
Cookies are on the client side;
Session is on server side;
Then the following questions arise:
How does the browser and/or the server know that the user has already
logged in and does not need to log in again?
If the Session stays inside a cookie what's the difference?
Where are cookies stored? In the web browser?
I use the (Blackberry?) passport (browser?) but it does everything by itself. I want to better understand how it works behind the scenes.
My affirmations can be wrong. You can correct me, but please explain to me.
Regarding what you understand to be true:
Yes, when setting a cookie, you can specify how long it will persist. In the article HTTP Cookies in Node.js, see the section entitled
"Adding Cookie with expiration Time".
Yes, data can be stored in a
session if it is explicitly placed there by application code. Your server software may also use it to store other information. Here
is a nice short YouTube video on node.js sessions.
Cookies are stored in a file on your computer which is managed by your web
browser, so again, correct. Here's a nice article that explains in more detail: Cookies - Information that websites store on your computer.
As to your other questions:
How does the browser and/or the server know that the user has already
logged in and does not need to log in again?
It generally knows this by storing a cookie in your browser whose value is some sort of session ID that acts as an authentication token. When you are successfully authenticated, it will store a cookie and send this cookie's value as an HTTP header or as part of the URL string, etc. each time you make a request to the server. This token is stored on the server with some sort of expiration time, usually something like 15-60 minutes. The expiration timer is reset to zero with each successful request. If session timeout is 30 minutes for example, the token will be invalid after no request is made within 30 minutes. Therefore, if you walk away from your computer for an hour and try to access another page, you will likely be told you need to log in again.
If the Session stays inside a cookie what's the difference?
As I stated in the answer to the previous question, an authentication token is generally stored as a cookie and sent with each request. It's good to use over and over until the session times out.
So, the difference is: A session is stored on the server. A cookie is stored as a file on your computer by your browser. A session cookie is stored on your computer which is used by the server to track individual user sessions.
Where are cookies stored? In the web browser?
Yes, as stated above, cookies are stored in a file on your computer which is managed by your web browser. See the article I linked to above for more detail.
First off, some general facts.
A cookie is stored in the browser and then sent back to the target server with every request to that server.
A cookie can either contain actual state data (such as backgroundColor=blue) or it can just contain a token that only means something to the server.
Whoever sets a cookie decides how long they want it to last before it "expires". If the server sets the cookie (as cookies can also be set from within Javascript in the web page), then the server decides how long they want the cookie to last.
A server session consists of the server creating a unique token and putting that in a cookie that it sets for that browser. In parallel, it also creates a session object that is stored on the server and it creates a means of associating the token with a particular session object such that when a request comes in and it has a particular token in it, the server can find the corresponding session object.
Note, sessions don't have to use cookies. They can also put a session id in the URL itself and that is occasionally used, but isn't very popular for a variety of reasons.
How does browse and / or server know that the user has already logged in and does not need to log in again?
A server can consider a browser to be already logged in if it finds an appropriate cookie in the incoming request and if it finds an associated session object in the server-side session store and if that session object is both logged in and not expired.
If the Session stays inside the cookie why is this difference?
Usually, when using server-side sessions, all that's in the cookie is a unique token - not any of the actual session data.
Where is the cookie stored? In our browser?
Yes, it's stored on your hard drive by the browser and then sent as an http header along with every request to the server that the cookie is associated with.
I am using node.js. I was thinking of just storing a session id in the session variable, so that every time I make a request for a route, the server checks in the database whether the user with that session id is authorised to access that page.
This seems a bit inefficient, since there will be a database call for every page request. I know I could just store some data in cookies / session variable for this purpose to avoid the database call, but then I am susceptible to tampering..
How do other web developers handle this ?
A server-side session and associated encrypted session cookie used with https is secure. So, just keep a value in the server-side session that tells you whether that user has been authenticated or not and all you have to do is check that variable in the server-side session object. This is how every web-site I know does things.
The NPM module express-session used with a suitable session store will implement most of this for you.
If you have a specific reason why you think this isn't secure, please share those reasons so they can be discussed.
Here's a general article about securing node.js servers and point #6 is about securing session cookies: 9 Security Tips to Keep Express from Getting Pwned.
I'm learning to use the "client-sessions" package in Node.js, with Express. Everything seems to be working well. But I'm wondering, is there is a way to have it call a function if a session expires?
I'm setting things up so that the session only stores a unique ID. Then outside of the session I store all the user data and anything else I need. That way it keeps my cookies and session info very small. But I want to know when a session has expired so that I can clear any info that doesn't need to be kept after the session is gone.
But I have not been able to find any details on how to do this. Am I thinking about this in the wrong way? If I store everything in the session it will try to store it all in the cookie as well won't it?
thanks in advance.
Making my comments into an answer since it appears to have helped you solve your issue...
If you use a session manager like express-session that only stores a session ID in the browser cookie and keeps a session object server-side in the session store, then you can just store your data directly in the session object and when the session expires, the session manager will just automatically clean up the session (including your data in the session). Then, you don't have to worry about when it expires as things are just managed for you automatically.
express-session has the ability to look up a given session in the session store.get(sessionID, callback) where store is the session store object you're using. To use that, you need to have previously saved the sessionID for a given user that you want to look up.
I am writing an ExpressJS backend with User login support. From multiple examples I see the use of req.session object. It seems this object is used to store and retrieve information across server and client, so the server can set a "logged" flag and later check this flag to see if the user has logged in.
My question is, how exactly does this work? How does the server store information on the client and retrieve it from every request, is it through cookies? Is it possible for a client to manually manipulate the content of this object on the client side to foil security? If it is, what is a more secure way to check user login?
I found something from the ExpressJS Google group, so a session and cookie is a bit different in ExpressJS. Basically:
Res.cookie adds a cookie to the response; req.session is a server-side
key/value store. Session data lives in server memory by default,
although you can configure alternate stores.
You can store anything you want in a session. The only thing the
client sees is a cookie identifying the session.
(Credit goes to Laurie Harper)
So it seems ExpressJS is already doing what #Vahid mentioned, storing the values on the server and saves a key as a cookie on the client side. From my understanding, req.session uses its own cookie (which contains just a key), independent from req.cookie's custom cookie.
Actually session object in req.session is not passed by client. In your syntax u might have used app.use(session{options})
This is a middleware. Now each request that is passed from express server has to be passed through this middleware. This middleware fetches the cookie(just an encoded version of sessionId stored on server) and decodes it to get the sessionId. The session corresponding to that sessionId is fetched from server and attached to req object as req.session. It gives a feel that we are getting session from client side, but actually it is the work of middleware to attach session object to req object by getting the cookie from the client.
I don't know your exact implemention, so I don't comment specifically for your case. But generally you can verify what's being sent from browser to server on each request, you can install a firefox extension like "Live HTTP Header" or "Tamper Data" or even a wireshark (if not https) or firebug, firecookie etc.
Then check to see what's being sent via Cookie, I'm sure that ExpressJS thing after successfully authenticating user generates a session ID, stores it in a DB and stores same value in your browser cookie. On every request (even images) your browser sends cookie, server verifies session ID with db and detects your session.
I've seen some old unsecure codes which sets user's session with a value like loggedin=1, if it's your case, you have to know it's really easily bypassable. You have to generate, save and set session ID per client.