I have enabled multiple logins in the dashboard and set the maximum number to 10. I have two devices that I test my app on. The problem is that if I am logged in on one of the devices, I cannot login on the other. I get the error message 3044: “Unable to login. Multiple login limit for the same user account has been reached”
There are only two devices and ten simultaneious logins are allowed, but I still get 3044 when logging in twice. I have to log out on the first device to be able to login with the second, and vice versa. Why?
Backendless Version (3.x / 5.x, Online / Managed / Pro )
Client SDK (REST / Android / Objective-C / Swift / JS )
We will investigate this issue and will keep you informed.
The last time your support staff said that I never heard from you again… ;o) Could you give me an estimate of when? A few days, a week? Thanks!
When your app uses the login API and a user successfully logs in, Backendless creates a user session. When the user (same or different one) logs in with the same credentials again (for example when they restart the app), Backendless will allocate another session. The number of these sessions for the same credentials is limited to 10. If your application does not check if the user is already logged in and the session time out is long enough, it is very likely that the scenario which you described will occur.
What can you do to avoid it?
- If you use persistent session, i.e. the
stayLoggedIn argument is set to
true, make sure to check upon app start if the previous session is still valid. You can do that by checking the validity of the user token.
- If the session is not valid or the user token is not present, then direct the user to the login screen.
- If you do not use persistent sessions, make sure to use the logout API when the user exists the app.
Do you use REST API or one of our SDKs?
If you use REST, you need to store the
user-token value on the client side after successful login and use it for the subsequent app launches… The value represents the login session.
As I explained above, I check for a valid session using the url format that you describe in your docs. The last parameter of that url is the user token, which I store in the db, otherwise I would not be able to check if there is a valid session. In other words: I store the user token and I always check if there is a valid session before creating a new one.
I also had two other questions who’s anwers may help us forward:
I searched the docs for stayLoggedIn but it said “No matching documents”. Where can I read more about this and how it is used?
Could this be solved by simply disabling Multiple logins?
stayLoggedIn argument is available only for the SDKs. You can see here, here and here.
You can disable multiple logins on the Users > Login screen of Backendless console. When turned off, any new login session will override any existing one.
Ok, so disabling multiple logins would “solve” the problem in so far that there would be no error message but it would still give a less than optimal user experience.
Is there somewhere I can see the active sessions for a specific user? Maybe if I could monitor them in real time I could see what happens and why it doesn’t work.
There is no visual interface to see active sessions for a specific user.
In the scenario you described in the original description, do you use a test user for which you know you have only one active session?
I only have two devices that I use for testing (iOS and Android) and I use my “real” fb account. I don’t see where any other active sessions would come from. So, yes.
By the way: I assume those 10 active sessions are per app?
Yes, all configuration settings are per app. We will verify the use-case you described and report back to you.
Ok, thanks! Let me know if there is any additional info I can provide to help in your inquiry.
If there is no visual interface to see active sessions, is there e.g. a url I can all to get some stats on this?
Not at the moment, but we will consider adding a management facility for that.
Btw, for tracking purposes the internal ticket number to investigate this problem report is BKNDLSS-19412
I could not reproduce the problem described above. I went through the following steps:
Enabled Multiple Login option - set value to 10.
- Logged in a user via Facebook and obtained user-token - client 1 (successfully)
- Logged in a user via Facebook and obtained user-token - client 2 (successfully)
- Made an API call from two different clients with different user-tokens. None of the clients are getting the error regarding invalid user-token, which means that both sessions are valid
Client - REST. Also tested with JS SDK. I went through this scenario several times and I never received an error regarding Multiple login limit.
Everything works as designed from Backendless perspective. I believe you’ll need to take a closer look at client-side code.
That is strange…
What are the ways a session can become invalid? I’m guessing two:
- Session time out as set in the dashboard
- Explicit logout from the app
Are there any other cases?
Consider this testing scenario: I install the app on my device, and log on with fb. That creates a valid session at Backendless and the user token is stored locally. After that, I delete the app and re-install it (new version since I am testing my app before launch). The app database with the token is now gone and my app will therefore act as if there is no valid session and ask Backendless for a new. What will Backendless do in this case. Will your system refuse the request since there already is a valid session or will it just create a new session?
If Multiple login option is ON - will try to create new session.
Then that could be the problem. I am currently testing my app before launch and I delete and reinstall the app on my local testing device several times. That means that each time I do that, a new session is created and the old ones are left in a “zombie state” since the session token is gone when I deleted the old version from my device. When I have done this 10 times, I cannot log on any more until a session expires after a very long time (since I use the max value 1410065407 seconds in the field “inactivity time” in the dashboard).
This means that a user can accidentally lock himself out of the system with no possibility to log in again in several years… Is that correct?