what i am wanting to do is to implement an email first login strategy using the iOS SDK. the idea would be similar to the login system that google uses. The following would be how i see the process working:
The user enters an email address and then presses submit.
The system would check if that user is registered
If they are already registered, the system asks for their password to log them in.
If they are not registered, the system asks them to register.
What would be the best way to implement this using Backendless?
Would it be possible to log the existing user in using this process if they had multiple emails linked to their account, and entered a secondary email?
Hi Alan,
Please consider the following approach:
Step (2) in your list would be performed by a custom service deployed in the API Engine.
The app asks for the user's email address and sends it to your service running in the API Engine.
The service logs in with a specialized account which would have the permission to query the Users table. Once logged in, the service would perform a query on the given email address.
If a user with the email address is found, the service would return a value indicating it (say "true"). Otherwise, the response would be false.
Once the client gets the response, it would display either the password field or the registration form based on the value of the response.
Regards,
Mark
oh ok so it looks like I’m going to have to create a custom event handler then.
can you elaborate on what you meant in step 3 though? I’m not sure what you meant by it using a special account to log in to.
i also have an idea for using an (almost) passwordless login system using mostly one time passwords.
here is what I’m thinking, starting on step 4 from your list above…
If a user with the email address is found, the service would return a value indicating true, send a one time password to that email address, and save that password to the user table (under "one-time password").
if a user was not found with that email, the server would return false
Once the client gets the response, it would display either the password field or the registration confirmation alert based on the value of the response.
The user either uses the one-time password to fill in the password box on the login form or accepts the registration alert.
the server then checks the one-time password with the one saved to the user table, if successful it queries the current users password in the "Password" field to log the user in, and it also deletes the value of the "one-time password" field. if the user just registered it follows the steps above and assigns a random password to the "password" field
To also implement this feature the handlers i create would need to have access to query the selected users password, and to send emails from the server. the two questions i have about this is, is this even possible? and if it is, would it still be secure?
The “special account” I was referring to would be a record in the Users table. You’d use that user account to login from your custom business logic code and perform all subsequent queries under that identity. The reason I would recommend that approach is to secure access to the same Users table (do you know how to do that?). If the table is accessible without that restriction, the system could be compromised.
The “passwordless” approach you described would work, however, there is one additional step. When the server logs the user in, it will get the user-token value. That value is crucial in Backendless API and is used to represent users identity in all subsequent calls. Once the server has user-token for the current user, the value of the token must be returned to the client and set in the SDK. The SDK then inserts the user-token header with all subsequent API calls.
As for how secure the approach you described is, it would be as secure as one’s email inbox…
Regards,
Mark
I’m guessing if i were to create the special account, i would need to automatically login to that account with my custom business login and then have it logout to switch users to the found user.
In terms of the User-token, I’m not sure how they work. Does Backendless automatically assign a user-token to all the users? If so where do i find it? the only place i can find documentation on the user-token is a really small paragraph in the login documentation, and that doesn’t give very much detail. To implement that wouldn’t i just need to query the “user-token” field after logging in the user and save the token somewhere on the users device to be inserted with all other requests?
Hi Alan,
Backendless generates and assigns user-token to the sessions started with the login operation. The value should be used in HTTP headers for subsequent API requests in order to “assign” user’s identity to the requests. That will force Backendless to apply the security permissions on the assets (data, files, media, etc) associated with the user and his roles.
Once you login the user, you will get back user-token, which you will return back to the device. On the device’s side, you would store the user token and re-use it later. However, keep in mind that user-token would expire at some point. You can check if it is still valid using API. For example, here’s how it is done in Android:
https://github.com/Backendless/Android-SDK/blob/master/src/com/backendless/UserService.java#L748
If user-token is no longer valid, you would need to perform the login sequence again.
Hope this helps.
Regards,
Mark