After a colleague of mine imported a user into our server, the user was unable to login through the Android app. The error message at login was that “This user is already logged in.” This happened continuously over several hours until escalated to me.
As it turns out, the usernames for these users were malformatted (had " "and “/”). When these were removed, the user was able to login.
So! Points are as follows:
The user extended app from @eyeseetea seems to bypass username constraints. I assume this means that the same would be true for import/export of users, but I haven’t tested
For android, is there a way to allow for 1 user to log in multiple times? Indeed, this is a common solution for us in particular for testing purposes on non-prod servers where we can set up a single user for data entry and pass credentials to multiple devices (all who sign in at the exact same time, more or less). We’ve never experienced any issues here on 2.8.2 nor 2.9.1.1; is there a possibility that we won’t be able to log in if users are already logged in?
The sense of “already logged in” feels pretty vague for me, given Android will only ping the server when initially logging in, syncing configuration, syncing data, etc. But in general an android device can be “logged in” but, I’m assuming, would be “logged out” from timeout at the server level. Given the ambiguity here, I’m curious if this feature is something useful.
Hi @Matthew_Boddie for the report. We will check if the behaviour of User Extended is different than import/export and decide what to do form there (my guess, as yours, would be that the same will happen).
Sorry for the late reply, I just became aware of this issue.
I think there might be some issues in the Android app when the username contains " " or “/”, I have to check it. And maybe the error message “This user is already logged in.” is not the actual cause. This message is displayed when there is an already authenticated user in the Android app.
Regarding the point 2, there is no restriction on the number of devices simultaneously logged in with the same username in the same instance, it shouldn’t be a problem
What Android app version are you using? I’ll try to replicate it.
Quick follow-up confirming your point 1 with the analysis we did on our side, plus what we are working on now.
Root cause we found. The Android SDK uses the username as part of the local DB filename. When the username contains a /, file creation on the device fails, which leaves orphaned credentials behind and surfaces as the misleading “This user is already logged in” message that Victor mentioned. Spaces cause similar downstream issues. So the misleading message was a symptom — the actual problem was the malformed username being accepted at creation time.
Why User Extended was permissive. A while back we had to relax the username regex (the standard A–Z, 0–9, ., _, @, - set) to support some legacy WIDP users whose usernames pre-dated the stricter rules — otherwise the app couldn’t read or edit those users at all. The unintended side effect is exactly what you hit: invalid new usernames could be introduced through create/edit/CSV-JSON import.
What we are working on. next version of user extended will re-enable the strict regex on the create while keeping the read path permissive — so legacy users keep working on user extended you will not be able to create new broken usernames.
Two things this fix doesn’t cover:
Users already created with bad usernames will still fail to log in on Android until renamed — the fix only blocks new ones.
Changing how the Android SDK surfaces the error would be great.
We released User Extended v1.7.0 recently and it includes a change of how we treat not allowed characters in user names. We apply a stricter validation to new users (that would not allow a user to be created with a non allowed character) but allow existing users with said characters to be updated.