User authentication: lost password function?

[WhenInSpace]

The whole user account management and email verification feature is great and easy to set up and use. But what would be the best way here to create a lost password function, to allow the user to get a new password, without having to recreate the account?

[mark_talluto]

You can export a blank stack from LCM. From there you will find a working login in card. There is working code for sign in, create an account, and forgot a password. We made this to get everyone started on how to work with the Users features.

How to export the working code.

1. Select one of your projects or create a new one.
2. Hover over the project name and click on the export tool kit button that appears.
3. Press the 'Create Project' button
4. This will generate a folder with a LiveCode stack called 'login.livecode'.
5. Load this stack into LiveCode and give it a spin.

-Mark

[WhenInSpace]

Thanks, I find a lot of useful code in that stack, that I can use in the login interface I've already started on.

However, I fail to find the "lost password" part, which is what I need most at the moment. 

It is more tricky of course - ideally it should be an email sent to the user with a link that gives access to an interface where they can set a new password. This works fine with web based services, but maybe not so well with LiveCloud? So instead, I suppose my application should create and save a temporary password for the user's account, and then send that password in an email. 

The user can then login to my application again, and there I need to provide a change password function, so they can choose their own one again.

Does that make sense? Or is there an easier way?

[mark_talluto]

I see. We did not supply a forgot password feature in our provided log-in code. We did create such functionality in LCM, but did not API it for use by others. I will make a note to add this to the log-in code.

[WhenInSpace]

OK, thanks, that would be great.

[WhenInSpace]

Coming back to this issue, I’ve tried to find a solution, but it fails.

Here’s the scenario:
- The App requires users to register an account and log in.
- Now, User has forgotten his password.
- The App provides means for checking User email exists and generates a token, sent to User by email.
- To do this, and save the token to the cloud database, the App must authenticate with a universal account. So it does that per default at startup.
- User provides correct token, and a new password should be saved to the user’s account using cdb_updateUserAccount
- The App tries to update the User's account by calling cdb_updateUserAccount tData,tProjectName,”User’s email”
- LiveCloud instead updates the App’s universal account…   Even though it has a different email. The universal account is indeed the LoggedInUser, but it specifies another account for the update. 

So, is it a bug, or am I doing something obviously wrong? How can my app update the data (specifically the password) of a user who is not the LoggedInUser?

[mark_talluto]

That does not sound correct. I will give this a try today and see what I see. I am in that code today working on a forgot password API for users.

[WhenInSpace]

That does not sound correct. I will give this a try today and see what I see. I am in that code today working on a forgot password API for users.

Thanks. 

It seems that this input parameter to the cdb_updateUserAccount command:

• pEmail (String) - The email associated with the user's account.
  

does not have any effect. It updates the loggedInUsers's account regardless. At least in my project... 

[mark_talluto]

That does not sound correct. I will give this a try today and see what I see. I am in that code today working on a forgot password API for users.

Thanks. 

It seems that this input parameter to the cdb_updateUserAccount command:

• pEmail (String) - The email associated with the user's account.
  

does not have any effect. It updates the loggedInUsers's account regardless. At least in my project... 

The pEmail is deprecated. I updated the API. I filed a bug report to update the docs to reflect this change.

The cdbUsers table was designed to be a place where the developer could store data on their users. It also a place where the developer can store data outside the core keys we provide (profile details). We made it possible for you to make an app that would allow you to do CRUD on the records in this table.

How this works in practice is one of your users' signs into your app. Your app would have done a cdb_auth call to authenticate them. The user has a secure connection to the tables available in that given project (app). So far, so good.

You might have a feature that allows the user to update their profile information. You found that a user could modify their data. You also found that a user could modify other user's data. There needs to be some consideration on the app side and how you provide this feature. There needs to be a way to do this securely. It is the same feature that allows LCM to access this table and display all the data to you as a developer. 

To be secure, you could let your app prepopulate the email into a locked field. All other fields could then be unlocked fields allowing them to modify only their record. But I think we can make this better. I am adding a secureMode parameter to the cdb_userAPIhere. If you pass one of these cdb calls with that parameter set to true, the API will guarantee the user is securely passing credentials that would ensure they are only modifying their data.

Since you are in control of the read portion, you might not pass secureMode 'true'. The user is already authed and does not need this for most apps.

I would pass true on create, update, and delete. I hope this insight is useful. Let me know if you have any thoughts.

[WhenInSpace]

That does not sound correct. I will give this a try today and see what I see. I am in that code today working on a forgot password API for users.

Thanks. 

It seems that this input parameter to the cdb_updateUserAccount command:

• pEmail (String) - The email associated with the user's account.
  

does not have any effect. It updates the loggedInUsers's account regardless. At least in my project... 

The pEmail is deprecated. I updated the API. I filed a bug report to update the docs to reflect this change.

The cdbUsers table was designed to be a place where the developer could store data on their users. It also a place where the developer can store data outside the core keys we provide (profile details). We made it possible for you to make an app that would allow you to do CRUD on the records in this table.

How this works in practice is one of your users' signs into your app. Your app would have done a cdb_auth call to authenticate them. The user has a secure connection to the tables available in that given project (app). So far, so good.

You might have a feature that allows the user to update their profile information. You found that a user could modify their data. You also found that a user could modify other user's data. There needs to be some consideration on the app side and how you provide this feature. There needs to be a way to do this securely. It is the same feature that allows LCM to access this table and display all the data to you as a developer. 

To be secure, you could let your app prepopulate the email into a locked field. All other fields could then be unlocked fields allowing them to modify only their record. But I think we can make this better. I am adding a secureMode parameter to the cdb_userAPIhere. If you pass one of these cdb calls with that parameter set to true, the API will guarantee the user is securely passing credentials that would ensure they are only modifying their data.

Since you are in control of the read portion, you might not pass secureMode 'true'. The user is already authed and does not need this for most apps.

I would pass true on create, update, and delete. I hope this insight is useful. Let me know if you have any thoughts.

Thanks, these are all good things to know.

If I understand correctly, the cdb_user API is currently designed so that editing rights of the cdbUsers table is limited to the currently authed user’s own data, and the pEmail parameter has no effect and is deprecated. Right?

So, the problem I need solved here is when the user cannot be authed because the password is lost. So it has to be updated through the credentials of another user account (like the app’s universal account).

Do I understand you correctly that the new secureMode parameter you’ll add to the cdb_user API would provide this possibility? 

I can of course already update the cdbUsers table using the standard cdb_update command. But it doesn’t work for the password. It does not get hashed when updated this way - it’s stored as plain text (and then the login attempt fails, of course). 

So the key question remains: How do I update a user’s password without first authing the user, and without using LCM?