<@292333473786494976> Can you please help?
# support-questions-legacy
m
@nkshah2 Can you please help?
n
Hi @malikkhoja What backend sdk and version are you using?
r
This is the original question (for reference): We are using SuperToken(3.2.0) in our React Native Application(0.70.6) Android. We encountered an ANR issue in few of the devices where SuperToken goes in loop to get the access token and which results in ANR. One Scenario we encountered is if user changes the date or time it occurs
m
Ok
r
@malikkhoja which backend SDk are you using?
m
supertoken/node - 12.1.5
Sorry for the late reply
We can see in our backend, that multiple sessions are been created for same user. Can this be a reason for ANR?
@nkshah2 @rp_st Please let us know as this is creating lot of issues at our end in Production environment
r
which frontend sdk are you using? ANd which version?
> that multiple sessions are been created for same user. What do you mean? There should only be one session per user login right?
m
Yes there should be
We are using SuperToken(3.2.0) in our React Native Application(0.70.6) Android.
Can you help us understand what can cause multiple session to be created?
r
which version of our frontend SDK are you using?
and which frontend SDK?
> Can you help us understand what can cause multiple session to be created? One use login should create one session for them. So if a user logs into many devices at the same time, they will have multiple sessions - one per device.
m
Ohk
SuperToken(3.2.0)
Front end sdk version
r
which sdk is this?
android? ios? react native
"SuperToken(3.2.0)" -> whats this?
> if user changes the date or time it occurs This can cause issues in which the backend and frontend go out of sync.. so if the date / time is not the real time, it can cause this.
does the infinite loop happen even if the user does not change the date / time?
m
react native
r
you are not being very helpful. Im sorry - can't really help out here without more info on what might be wrong
m
What info do you need?
r
- how to reproduce the issue. - If you have any backend debug logs. - If you have any backend error stack trace relevant to this issue.
m
For all of my customers, device id is empty in supertoken. We believe this is causing multiple sessions.
Can you help me understand from where does SuperToken picks Device ID?
r
it doesn't
im not sure what you mean by device ID
m
Ok, so how does super token identifies unique user? As you mentioned earlier, it will create a unique session for one device
r
based on the login method
m
there is a table passwordless_devices
What do u mean by Login Method?
r
that table is only used during login.. it stores the passwordless login session.
m
we are only using passwordless login method
r
right..
m
and we can see multiple session created for same user
So we need to understand the root cause that why it would be happening
r
are they logging into multiple devices?
m
No
r
is your session flow even working?
refreshing / sign out etc.
m
Also, how do u even identify unique devices?
r
when you sign out, does it clear the session from the database?
> how do u even identify unique devices? We don't need to!
this issue has nothing to do with passwordless login
first we need to make sure that session works
does sign out work as expected?
m
Yes it works
Signout is working fine
r
it clears the session from the db?
whats this issue about? infnite refresh loop or something else?
im quite confused.
m
Yes it does. When user doesnt do signout and the session is still open
r
hmm. okay
m
So for example. if I login today with password less method and then next day if I open my app then it doesnt gets opened
and multiple sessions are created
no Signout done
here
r
hm
you can reproduce this issue?
m
Yes we can as it causes ANR
r
whereall are you creating a session on the backend?
m
Android Not Responding and it crashes the app
r
whereall are you creating a session on the backend?
m
Only when the user logs in
r
right. So you are saying after one day or logging in, when i visit the app, it causes multiple sessions to be created? Does this happen if i visit the app lesser than one day after logging in?
m
No it doesnt
r
hmm.
m
It happens after one day only
r
24 hours? Or just past midnight?
m
and when I clear my app data, everything works as it clears all the token from the cookies
past midnight
r
i see.
m
as we have tested this with less than 24hrs also
r
what are the API calls that are made when this happens? Do you have logs for that?
m
Unfortunately no
r
if you can reproduce it, then maybe you can see the backend logs at the time this happens? I would need more info
m
hmm ok
We are just trying to understand why multiple sessions are created
as we revoked all session of a internal user except one, latest session and it works
r
we can get there.. let;s first see which APis are being called. Then we can see what those APIs are doing.
m
Ok
auth/signinup/code auth/signinup/code/consume
1st one to create the otp and second one to verify it
r
right. So each time the
auth/signinup/code/consume
is called, it will create a new session (if the request body is right)
do these APIs get called on their own? How does the consume API know what the code is without the user entering it?
m
No it wont get called automatically
One scenario can be, if a user log's in by calling consume api, then does clear data so all session is broken and then user enters the mobile no and otp by calling consume
a new session would be created and this will lead to multiple session
as logout was never been called
ideally if there is a valid session exists then consume should return the same session rather than creating a new session. Correct me if wrong
r
not really.. consume should create a new session. It's better from a security point of view.
The scenario you describe makes sense, but it;s not in line with what you said earlier where it causes an infinite refresh loop and that after midnight, somehow new sessions are created.,
I think you need to get clarity on what's happening.. only then i can help (since this is free). Good luck
m
Thanks for the quick revert. We understand that we have been discussing multiple scenarios here as our whole agenda is to find the issue. As we feel discussing multiple issues would help you understand our problem better and help us understand what we are doing it wrong.
r
let's try and solve one issue at a time.
m
Sure
r
The consume code API creating a new session is expected.
m
Yes
r
if the user clears their app data, they will be logged out, and when the login again, it will get them a new session - this is expected. You could override the createNewSession on the backend to revoke other sessions belonging to this user if you want, but this would also mean that if the user has indeed logged into another device, their previous devices would be logged out.
m
Ohk
supertoken-reactnative - 3.2.0 supertoken/node - 12.1.5 supertoken docker - 4.4.1
Just for information, sharing the version no used across all the end
As consume will create a new session every time - expected behaviour, then how does SuperToken identify unique user or devices? or it doesnt?
r
it doesn't need to
consume should only be called when the user is logging in
which should only happen if the user is not already logged in
m
Also, docker server was started again a month ago, and when we started it pulls up a new image of the version and we can see the increase in this issues since march. Do you think this can be because of the updated version or version mismatch?
Ok so in case of clear data you recommend to clear previous user session(if any)
r
The new core should be working with the version of the SDK you are using. But you should ideally not have it auto pull the latest core. That’s generally a bad idea.
Not really. I would say keep it as is. But you could clear older sessions when a new one is created (as I said before)
m
Ok