Pretty cool. Thanks
JWT: Has anyone had to handle timing out logins after a period of inactivity?
Are you using the refreshToken mutation to renew the token?
Not currently - I’m still trying to get my head around this. How would we build that in normally? Does that mean we send refresh requests from the FE?
Depends how you want to architect it really. Are you using Apollo to handle auth/graphql requests?
You could poll the server to check if the token is valid (there is a valid query as well) If you are using apollo you could build middleware to handle the if the query fails due to auth then try a refresh of the token and then retry the query otherwise log the user out
You could then expire the token on the server so the user can’t refresh after a certain peroid
This is a great article explaining an ideal workflow - https://blog.hasura.io/best-practices-of-using-jwt-with-graphql/
JWTs are becoming a popular way of handling auth. This post aims to demystify what a JWT is, discuss its pros/cons and cover best practices in implementing JWT on the client-side, keeping security in mind.Hide attachment content
Hmm doesnt the refreshToken mutation work pretty well=?
Thanks @gened! I missed your responses somehow.
I built an endpoint to check if the token was still valid. Currently its called on route change, though I have some reservations about that
No problem, are you using apollo?
yep, + react + mobx
The SS JWT module has a validateToken mutation
Yeh not sure route change is the best option.. the way i do it is if a request returns unauthorised, i try to refresh the token.. if that fails i log them out. I do this by an apollo onError link
So, how do you know its unauthorised?
In our case the endpoints aren’t protected, there is just slightly different information displayed if someone is logged in
In that case not sure, i handle it via error handling and overriding the graphql Manager’s error handling
Found it a bit of a sore point in working with SS graphql tbh
you’d need to put it on every endpoint then?
Depends how your want to architect it, middleware could work. Or via Exception handling. On handling of a certain Exception you could return an auth error
Oh right, yeah that would work
I really wish this stuff came with an opinionated architecture
but there seem to be a million ways to do the thing, and they all feel a bit like hacks
Its strange that logout is such a … bolted on piece of functionality in a system used for auth.
Yeah, silverstripe graphql is only in it’s infancy. So it doesn’t have much of an opinion i suppose. The docs suggest throwing an exception, but that is as far as it goes.. i suppose any more opinion is then telling the dev how to build their FE app. It might be good to look at what Apollo server or Graphcool do
Oh, I meant jwt in general. The number of articles that are like “jwt doesn’t support logout, but here’s how you can ignore normal jwt rules and logout anyway”
Well if the JWT isn’t there or it is invalid then you are logged out 🙂
Is it normal for the JWT module to get confused when there is a CMS user logged in at the same time? For instance, logOut sometimes fails when a user is logged into the CMS with a different account.
I guess its a bit of an edge case. It’d mostly catch devs and testers
Yes, it will get confused, because it's the same session server-side
JWT at the moment is not 100% stateless, as it uses SilverStripe as both the provider as well as the client for the JWT tokens
If you have a valid "normal" session, JWT will use that if you log in using the same browser. A workaround is using a private browsing mode
Sorry, I are not purrrfect
And also, lacking about 24 hours of time per day
@greg_808 has left the channel