06-14-2019, 09:06 AM
(This post was last modified: 06-16-2019, 09:56 AM by WhenInSpace.)
(06-13-2019, 09:51 PM)mark_talluto Wrote:(06-10-2019, 03:10 PM)WhenInSpace Wrote:The pEmail is deprecated. I updated the API. I filed a bug report to update the docs to reflect this change.(06-10-2019, 02:43 PM)mark_talluto Wrote: 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:does not have any effect. It updates the loggedInUsers's account regardless. At least in my project...
- pEmail (String) - The email associated with the user's account.
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?