https://supertokens.com/ logo
Join Discord
Powered by
Hey <@498057949541826571> I've had a case that our...
# support-questions-legacy
u
Hey @rp_st I've had a case that our administrator deactivate user on our dashboard. The expectation is to kick the customer out of the app. To do this, we need to invalidate the access token that user used by that time. After we implement access token blacklisting, we can't force sign out customer as we don't have user token when deactivating user is performed by administrator. Question, is removing sessions for user would handle those case ^? Or is there any other mechanism that Supertoken provide to handle that?
r
hey @[CATs] ya ong | [GUnS] bakins you will need to revoke the session from supertokens. This would remove the refresh token from our database so that when the user refreshes the session, it will fail and log them out. Now of course, if their access token is still valid, it will continue to work, unless you have the 
checkDatabase
boolean set to true when you use getSession / verifySession. Or, if you have your own blacklist. In this case, you can send a 401 to the frontend. This will force trigger an early refresh, which would fail (See 1st paragraph in this message).
u
@rp_st given your explanation, meaning if we already implement checkDatabase true and calling revoke session, it's doable to invalidate the user rightaway after we deactivate user? I am trying to maximize Supertoken feature on this.
r
yes. It will kick the user out immediately in that case
u
great, let me try to implement that and get back to you soon, thanks
Hi @rp_st I want to raise something about access token blacklisting. We have a case that this token is still valid but getting unauthorize error 401 after calling VerifySession()
Copy code
eyJraWQiOiJkLTE3MTE3OTk4OTYxNTUiLCJ0eXAiOiJKV1QiLCJ2ZXJzaW9uIjoiNCIsImFsZyI6IlJTMjU2In0.eyJpYXQiOjE3MTIxOTI0NzUsImV4cCI6MTcxNDgyMDQ3NSwic3ViIjoiZjdmZWIyOWQtYWU4Zi00YjIwLWE0ZWQtOGVmMTU2Yzg4YjEwIiwidElkIjoicHVibGljIiwic2Vzc2lvbkhhbmRsZSI6IjEwMWQ2Yjg2LWQ0NWQtNGFjYy1iZWI0LThlYzI0ZGM2YTMyZCIsInJlZnJlc2hUb2tlbkhhc2gxIjoiNTgzMjQyMmU4Y2YxYjQxNjc0MGIyMjRiNDA3N2Y2MGQ4NWU0ODRiMDNiN2Y1OGJiZWRjMTg2ZWMzNTRlMjlhNiIsInBhcmVudFJlZnJlc2hUb2tlbkhhc2gxIjpudWxsLCJhbnRpQ3NyZlRva2VuIjpudWxsLCJhdWQiOiJodHRwczovL2FwaS5hbmdrYXMuY29tIiwiZmlyc3RfbmFtZSI6IkZyZWRlcmljayBJdmFuIiwiaWQiOiI3ZjhjNjYxOC05YTNmLTQ2YmEtODFhZS04MDhiMTRlNDBiNzAiLCJpc3MiOiJodHRwOi8vYXV0aGVudGljYXRpb24tc2VydmljZS1hcHBzLXByb2QuYXBwcy5zdmMuY2x1c3Rlci5sb2NhbDo4MC9hdXRoIiwibGFzdF9uYW1lIjoiU2FnbWFxdWVuIiwibmFtZSI6IkZyZWRlcmljayBJdmFuIFNhZ21hcXVlbiIsInBuIjoiKzYzOTY2MTc4MTI3NCIsInNjb3BlIjoiZGVmYXVsdCBzY29wZSIsInRlbmFudF9pZCI6IiIsInRlbmFudF9uYW1lIjoiIiwidXNlcl9jcmVhdGVkX2F0IjoxNjY5MTE1NjM0LCJ1c2VyX3JvbGUiOiIiLCJ1c2VyX3R5cGUiOiJkcml2ZXIifQ.bdCem2dkBOTQ5Khc_GVVff7WWU-FmcGIk-fgSDcK6XtK_lZ1vjHDdNUlNpKd7Rp53vGz2PM2lcb2iCPj7ZXntDP4OBGDWy0Q1xYINd4lICtKFNj0t88WX720AUN4LC5PIjh6XLUoPSUvpyEomvgivslsdAzdIeKDITAdmkkkZt2cQKmFg8Wo9n0apf1OHjQvDSBpoESdUkOOyFty-KSlZkYVELny4rkFpTTwA9LxXUu0_Dj5jLXVLEoVgRqr9Z06CXrra2jZ2GxiMgzgEKQdTlOeIlekTX4XFZa5Q3J3beoiO2U5FYXSmZo3MeTpTvA7nvVVUKOec8aWt4-tU5d9aQ
Question is what would be the case of this token is unauthorized?
r
can you enable backend debug logs and show the output?
u
hmm, we're not able to reproduce it yet, and this is happen in production as we can't enable debug level rightaway. But I will do it in DEV & UAT env to monitor the case. Thanks for the suggestion and will get back if I found something
@rp_st need help to understand on when RESTART_FLOW_ERROR error happen upon consume code. Currently after implementing access token blacklisting, some customer users getting 400 error upon consume code. Our session implementation for customers is multiple session, means when expired or logged out, the session is still there. Is it maybe because of multiple session?
just confirm something, this also happen even before we deploy access token blacklisting
r
RESTART_FLOW_ERROR happens if the magic link is expired or if an incorrect otp has been used too many times.
Also, for 400 error, whats the response body?
> Our session implementation for customers is multiple session, means when expired or logged out, the session is still there. I don't understand what you mean..
> just confirm something, this also happen even before we deploy access token blacklisting RESTART_FLOW_ERROR has nothing to do with access token
u
noted on that
> Our session implementation for customers is multiple session, means when expired or logged out, the session is still there. @rp_st when customers re-login, it didn't revoke all the session that exist. So, the session will stacking like in this video. Will it affecting to the RESTART_FLOW_ERROR? I believe, the best practice is to have only one session at a time CMIIW
screen-recording-2024-04-04-at-9-08-34-pm
r
> I believe, the best practice is to have only one session at a time CMIIW You can implement this by overriding the consumeCode function and revoke all sessions when the original implementtion is successful
> Will it affecting to the RESTART_FLOW_ERROR? nope
u
@rp_st Had 2 questions: 1. What will be an impact in having a lot of session with long session expiration? 2. How to adjust the session expiration duration?
> RESTART_FLOW_ERROR happens if the magic link is expired or if an incorrect otp has been used too many times. also clarifying on this ^ what does 
if an incorrect otp has been used too many times.
means? does it means users inputting incorrect otp code?
r
1. Nothing as such.. it will just mean the user can login with all those session tokens. 2. https://supertokens.com/docs/session/common-customizations/sessions/change-session-timeout > does it means users inputting incorrect otp code? Yea
u
Understood on that all, just confusing since our QA input the correct OTP but getting RESTART_FLOW_ERROR issue. I will progress to adjust the revoke session & its timeout, thanks
r
Im not too sure how a correct otp would give RESTART_FLOW_ERROR, unless you have already tried an incorrect OTP too many times
PreviousNext
Powered by