I’m using the iOS SDK. After logging in creating objects works perfectly. I have set StayLoggedIn to true, so the user doesn’t need te relogin every time he starts the app.
Now after being logged in for several days, when creating a new object the ownerId field is empty in backendless.
For example objectId: EA3A2A5B-9917-87C2-FFDE-E6ED27816400 has this problem.
Any idea why this happens?
Sorry, I had to delete the object with id EA3A2A5B-9917-87C2-FFDE-E6ED27816400.
Anyway: Problem remains, any idea?
Hi Barry,
See the section “Validating User Login” on this page:
https://backendless.com/documentation/users/ios/users_login.htm
You need to make sure the user token is still valid. If it is not, then the user needs to login again.
Mark
Hi Mark,
Can I somewhere adjust the time a login is valid?
We really want the enduser to not have to login multiple times in the app? Is this possible? (one time login)?
A limit would still have to exist, but it can be high:
https://backendless.com/feature-83-support-for-customizable-session-timeouts/
Ok thanks. Weird that the article status that the default timeout is 1 hour. Then I would have had this ‘problem’ a lot earlier.
To work around this ‘problem’, I guess one option is to store the user credentials in the keychain, and run a login in the background whenever the application becomes active.
How do other people do this? If a user has to relogin every month (for example), that isn’t really user friendly?
In my mind it is not a question of user friendliness. It is a matter of security. If I have an app that allows “infinite logins” I would be quite concerned about it. If I ever lose my phone, anyone who finds it would be able to use the app as me and that’s a big problem. I cannot think of a single reputable app that would allow such form of “login”.
I get your point, however in most business environments there is a mdm deployed, where all devices are forced to be locked by a code / fingerprint. When a device gets stolen it will be wiped remotely.
If a device gets stolen, and the session timeout is set to 30 days, well then the problem is really the same as it would have been set to infinite imo?
Also, for the application that we are designing, an end user will only see the data that he is currently working on. So in a worst case scenario only very little data will be stolen.
A 30 day timeout is also unreasonable. The way timeouts work is they restart after last API call. That means that if the timeout is set to 24 hours and a user logs in daily, they will not need to re-login ever.
Ah, thanks a lot for clearing that up.
Would it be a problem to get a 60 day limit (with holidays in mind)?
Maybe a better question: Is the maximum session timeout time configurable (without limitations) on the standalone server (as that is what we’re planning to use)?
Should not be a problem. The Standalone edition will have the same setting.