Press "Enter" to skip to content

MERN Stack & GraphQL – #12 Session Lifetime


on the one last issue with
authentication that I’ll mention is that
when you sign in the cookie will be set
to expire after two hours and this is
regardless of the activity that you
might have so what I mean by that is
let’s say I’m signed in I’m going to run
a query let’s say on myself let me just
copy that query if we run that query
it’s not going to change the expiry date
of the cookies so note that at the
moment the cookie is set to expire
around twelve fifty nine twenty two
seconds so if I run the query again
you’ll see that the cookie will expire
at that same exact time and this might
be problematic if the user is using the
system but they’re being locked out
after two hours even though they’re
still active on the website so once
again this is coming back to the
discussion we had earlier about the
expiration time of the cookie so if you
look at the config file by default it’s
set to two hours and I think that time
frame makes sense but only in a use case
money session is being extended when the
user makes queries or otherwise makes
mutations to the system if the cookie is
set to expire after a fixed timeframe so
in this case two hours I think it makes
sense to bump that timeframe to let’s
say a day and once again I really
depends on the application and how its
set to function of course but I think
what we’re gonna do for this application
in particular we’re gonna keep this
session lifetime at two hours but
instead of making it fixed what we’re
gonna do is we’re gonna go back to our
index file
knotti directives let’s go to you source
slash index and now inside of this file
we’re gonna go back to our session
declaration and so or you need to in
this file is we’re going to actually
start resave to true and so what we save
is going to do is it’s always going to
persist the session back to the store
and this will happen even if the session
wasn’t modified so even if you didn’t do
let’s say request that session even if
you didn’t put let’s say the user ID or
any other property on that session
object so we’re always going to receive
the session back to the store and in
fact this makes sense to do because by
the end of every request the session
middleware will actually touch the
session store so it’s going to call
store touch method what that function or
method is going to do is it’s basically
going to bump the expiration time of the
Kuki now it’s not going to save it it’s
actually going to only bump the time to
live property in Redis and this is in
case of using Redis of course because
we’re using Redis for sessions and
because the time to live is already
being bumped up and there’s no way to
opt out of that behavior we’re gonna do
is we’re gonna call session that save
and this will basically persist the
session to the store that call is being
controlled by the resave property and so
once this session is being saved to the
store its life time is going to be
extended because the expiry date is
going to be extended into the future and
because of that we’re gonna also set the
rolling property to true this will
simply update the cookies so it’s gonna
make sure that the cookie is synced up
with the session server-side and if you
haven’t worked with the session Express
package all the stuff I’m explaining
might seem very cryptic and mysterious
so what I’m gonna do is I’m gonna show
you by example so let me actually go
back to the browser I’m going to sign
out temporarily so this will delete the
cookie so first of all let’s make sure
we don’t run into any issues it seems
like the server is running fine and on
the same note I’m actually going to go
back to this tab what I’m gonna do is
I’m going to log into Redis so lets me
call up Redis Eli we’re gonna pass on
the host I’m gonna grab it from the
environment file so I’ll pass in the
port and the password so once I’m logged
in let’s go back we’re gonna sign back
in so let’s call the sign in mutation
from this tab so now we’re signed in and
we also get the cookie notice that it’s
set to expire at 1 hour 6 minutes and 30
seconds in Eastern Standard Time if I go
back to the terminal let’s do a scan 0
we’re gonna see that session so what we
can do is we can do a get on that
session key so this will give us the
actual session object that is being
serialized into JSON you’re gonna see
that it’s gonna expire at 6 hours 6
minutes and 30 seconds this value once
again is greater by 5 hours because it’s
in GMT or you to see now if let’s say I
do a request with Amy query let’s take a
look at the session cookie in this case
as you can see it’s bumped up to 7
minutes and 43 seconds and that’s gonna
happen every time I make a request to
the server you can see once again in 1
from 43 seconds to 51 so every time you
make a request it’s gonna bump up the
session cookie so it’s gonna extend the
lifetime of this session and the same
thing is going to hop
of course in here so if we do a get on
that same session key the same is gonna
be reflected in the store so now the
session is going to expire he had 6
hours 7 minutes 51 seconds in GMT of
course if I make a subsequent request
that value will be popped up as well so
the reason that this is useful is it’s
gonna allow you to basically extend your
session indefinitely until it expires
after two hours of inactivity so if
you’re away from your computer for two
hours the session is going to expire and
you’re gonna have to log back in and on
the same note if you do the time-to-live
command it’s gonna give you the exact
same thing only in seconds now this one
actually goes down every second so as
you can see if I reach that value is
gonna be decremented basically it’s a
counter that tells when the session is
going to expire so now by the time it
reaches a negative value that means that
this session is expired and this session
will also be deleted from rattus now
that happens if you try to request again
from the server this command will fail
and on the browser side when the
expiration time for the cookie is being
reached the browser will delete that
cookie of course you could still copy
that value and in fact you could make a
cruller request with a cookie header but
that value won’t be accepted server-side
because by that time if the session is
expired it will be deleted from the
store so you won’t be able to
authenticate against that same session
and we hope that clears things up once
again all that explanation really was
about is the resaved property so we’re
gonna be receiving the sessions to the
store and every request and we’re also
gonna be rolling the cookies so we’re
gonna be resetting the cookie on the
response every time you ping the server
anyway soon that’s gonna be easier for
us because we’re gonna be able to make
requests to the server and also extend
the life time so if we are active in the
application if we’re making requests or
in the future we’re also gonna be
subscribing to data changes if we are
active with a session and make sense to
keep the session alive until we are
inactive and after we’re inactive we’re
gonna set the expiry of two hours once
that time is reached we’re gonna take
the user out of the session anyway so I
hope that makes sense and once again
we’ve refactored
the application to use the auth and
guest directives so hope that was useful
and I hope you enjoyed it let me know
what you think and I’m gonna see you the next time

Please follow and like us: