Session Values Deleting from Server But Not Login in NodeJS

Wappler General Bugs
,
#21

Would ttl and cookie maxAge apply to redis session as well?

This is what I show in config.json for redis

  "session": {
    "store": {
      "$type": "redis"
    }
  }
#22

The change suggested earlier had not worked. Will let you know how this one goes.
With the new change, I can see datetime in Expires column for the *.auth cookie.

Before:

image
image781Ɨ176 4.58 KB

After:

image
image700Ɨ109 3.51 KB

Question: Is the server side session variable stored under the session id that is in this client side session cookie? Which is why after some time the SA is unable to get the session values? But, the user isnā€™t logged out because login cooking *.auth is ok?

#23

The session cookie indeed contains the id of the session, without the cookie the server would not know which session belongs to the user.

tj/connect-redis: Redis session store for Connect (github.com)

It seems that when cookie maxAge is set and ttl is not set it will use the cookie settings. I donā€™t think it will set the cookie date. The ttl setting is how long the session should be kept in the store and the cookie when no expire date is set will be active until the browser is closed.

When you set the cookie maxAge, it is set in milliseconds.

#24

Is there a specific reason why you want to keep the session data that long, normally session data is only temporary for the time you have the browser open.

The logged-in user is also stored in the session, by setting the cookie expiration the session works like the remember me cookie which would then not be needed anymore.

#25

The flow is that when user logs in, I store their account type in server side session.
There are certain server actions which then use this session value to identify the user type, without having to query it again from the DB using identity.
But, because this session value expires, but identity remains, it results to either failed steps and error.

Is there an alternate to storing such information that I do not wish to query again and again from DB on server side?

#26

You know that you store your session also in the DB, so for each request it also has to query against the database to retrieve the data from the session.

#27

Yes, but I cannot add any data in thereā€¦ nor access whatā€™s being retrieved.
So just trying to save another DB hit to get that additional data.

Actually, that leads to another question: this session DB query run with the security restrict step, right? Or security restrict step is another query?

#28

The session DB query runs when a session variable is requested, so it will indeed also run on the security restrict step. I believe it is optimized to only run once on the first session variable that is requested and will not run when you donā€™t access the session. It also updates the record with each request to store changes or to update the expiration date.

The ttl/maxAge is the time it should keep the data since the last time accessed, so it gets updated each time the user interacts with it.

#29

Thanks for the explanation. Makes sense.

So any alternate suggestions to my use case? I am open to not using Sessions for storing data on server side.

#30

My redis extension will make it easy to store these things inside redis with a custom ttl @sid Iā€™m using it already to not hit the db so often.

1 Like
#31

We are not using Redis in this particular application, but I donā€™t think I would mind using it.
There are couple of other projects as well, which have the same problem and no Redis. If things work out here, other might follow suite.

Will know if Patrickā€™s latest solution works in some time. Waiting for your Redis solution as well. :slight_smile:

1 Like
#32

This seems to be working as expected.
Will try to replace this with Redis solution when possible.