4

I am currently working on a new project and I use sessions with the express-session library.

Here is the code where I set up the session:

const IN_PROD = process.env.MODE==='production'
app.use(session({
    name: 'sid',
    secret: 'asecret',
    store: new MongoStore({
        mongooseConnection: mongoose.connection,
        collection: 'sessions'
    }),
    saveUninitialized: false,
    resave: false,
    cookie: {
        sameSite: true,
        secure: IN_PROD,
        expires: new Date(new Date().getTime() + 1000 * 60 * 60 * 24)
    }
}))

Imagine the following steps:

1) My server sends a session id (sid=A) in a cookie to my client.

2) The client manually deletes the cookie

3) At the next request, the client sends another session id (sid=B)

Is it normal that both A and B cookies are stored in the database and the first one is not overridden?

blouuuu
  • 454
  • 1
  • 4
  • 16

1 Answers1

5

It is normal. It is up to either you or the session store you use to clean up older sessions.

If you look at the MongoStore() documentation, you will see that it has several features related to automatic removal of session objects.

Here's one example:

// connect-mongo will take care of removing expired sessions, using defined interval.

app.use(session({
    store: new MongoStore({
      url: 'mongodb://localhost/test-app',
      autoRemove: 'interval',
      autoRemoveInterval: 10 // In minutes
    })
}));

Keep in mind that at the express-session level, a session is just a blob of data associated with a cookie. Any time a browser makes a request to your server and no session cookie exists, a new session cookie is created and a new express-session object that is connected to that new cookie.

If the user then deletes that cookie and connects to your server again, express-session has no idea that this browser is the same browser as the previous session. The original cookie is the only way it could know that and the cookie is now gone. So, express-session just sees a new browser connecting to your server that doesn't have a session cookie so it creates a new cookie and then creates a new session object to go with it.

Any association of a logged in user with an express session is done at your application level (by putting user-identification information into the session object) and express-session is not aware of that at all.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • What if the cookie expires arter one month and someone deletes the cookie and refreshes the page 100 times, are these 100 sessions stored in MongoStore for one month? – blouuuu May 12 '20 at 16:45
  • @CustyZ01 - Yep. I'm not sure why it's a problem to have a few inactive sessions in your database that haven't aged out yet. A session shouldn't be large. It's meant only for temporal data, not long term user data. If you fully understand the explanation I have in my answer about how express-session actually works, you would not be surprised. And, nearly any major site faces the same thing, except most don't allow a logged in session to last a month. If you don't want them to build up very long in your database, then use shorter durations for how long you let Mongo keep the sessions. – jfriend00 May 12 '20 at 20:15
  • Ok it makes sense thank you but do you know why companies like Amazon have cookies that expires in 2035? Are they also storing sessions in some form of database? – blouuuu May 12 '20 at 20:55
  • @CustyZ01 - That's so they know who you are, even if your login has expired. That cookie isn't for something like express-session. Also, your permanent user data isn't stored in a temporal session object, it's stored in your permanent database record. I think maybe you're confusing permanent, long lasting user data with a temporal session object. They are not the same thing. For database efficiency reasons, you might copy some data from the permanent user database record to the session object (as a form of cache so you don't have to keep looking it up in the database). – jfriend00 May 12 '20 at 20:58
  • @CustyZ01 - And, by the way, you would only put things in the permanent user record once you have a logged in user and know exactly who they are so user records like that never accumulate, even if the user is messing with their cookies. – jfriend00 May 12 '20 at 21:00
  • I probably asked my question wrong. I am also trying to keep track of non-authenticated users like a shopping cart or something like that for a long period of time. That's why I want a long expiration date for my cookie. If express-session isn't appropriate for that thing, do you know another way to help me out I will be grateful. – blouuuu May 12 '20 at 21:09
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/213732/discussion-between-custyz01-and-jfriend00). – blouuuu May 12 '20 at 21:10
  • @CustyZ01 - You can use express-session for that just fine. You will just have no idea which carts are going to be abandoned and never returned to. So, you have to agree to store them for the duration of the long expiration in case the user comes back during that time. That's the price of saving data for a long time without login. And, yes, a malicious user could cause you to store thousands of carts by creating a cart, deleting their cookie, creating another one and so on. Is that really a problem? – jfriend00 May 12 '20 at 21:33
  • Thank you very much, it helped me alot. – blouuuu May 12 '20 at 21:39