• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Allow users to change their password?
#1
Hi Mark and liveCloud team 

Please accept my apologies if I missed this in the documentation - is there method for changing a user's password?

Thanks to a nice forum post from Mark, i saw there was an internal method (not mentioned in the documentation) to allow users to reset their account with a random string, but my users will want to change this to one they will remember after logging in...

I can't see a way to hash the new password provided by a user to update the cdbUsers record with the hashed version. Although i'm not sure, i don't imagine cdb_updateUserAccount would do this automatically.

As far as i can see, the only way to do this would be to get the existing cdbUser's data, delete the entry and and create a new user with the update password, which seems a faff, not to mention time-consuming function...

Is there a better way of doing this? (or will cdb_updateUserAccount do this automatically?)

Many thanks in advance,
Stam
  Reply
#2
Hi Stam,

Changing the user's password is as easy as including the password as part of the Input array.

Eg:
put "newPassword" into tInputA["password"]
put true into tSecureMode //optional

cdb_updateUserAccount tInputA, "userEmail", "usersCurrentPassword", tSecureMode

SecureMode considerations
If you pass true for secureMode, you will, as expected be more secure. This is because the currently signed in user's password will be used to secure the change. But, using this mode means that you should require your user to sign in again. Not doing so may cause other APIs to fail due to the password not matching the new password.

If you pass false for secureMode, you will be able to change the password of any user without knowing their current password. Your program UI can solve this by not allowing the user to change their email at the same time as their password. I would still have the user sign in again after successfully changing their password.

The hashing is managed for you. You do not need to worry about that.
  Reply
#3
Perfect, thank you!
  Reply
#4
Hi Stam,

We are working on an update that will not require you to authenticate a user after they change their password.

-Mark
  Reply
#5
(07-07-2021, 01:47 AM)mark_talluto Wrote: Hi Stam,

We are working on an update that will not require you to authenticate a user after they change their password.

-Mark

Thanks Mark,
While that would make things simpler, your advice above worked like a charm - the user is warned they'll be logged out and have to re-login if they change password; works well in secure mode.

Using non-secure mode to change any user's password makes less sense in my case - i would only need to reset a user's password when they can't login, so don't have to worry about logging them out, but i also don't want to know their passwords, so really  cdbi_forgotUserAccountPassword works much better for this

You guys are probably very stretched right now, but would be nice if documentation would include this info (especially about cdbi_forgotUserAccountPassword)

Many thanks for your help as always!
Stam
  Reply
#6
Hi Stam,

I did not realize that we did not document cdb_forgotUserAccountPassword. We'll get to work on that today.
cdb_forgotUserAccountPassword is useful for cloud data.

It comes with one caveat. Local data will no longer be accessible. This issue is a huge problem if your app relies on local data.

The reason is that we have a unique hash for every user. Thus, if your app runs on a community computer (think front office desk with multiple users logged into their accounts), the unique data each person has access to is protected by a unique hash. Thus, no one can drag records from another account into their DB and expect to access the data.

The problem is exacerbated when you consider data stored on multiple devices. We cannot simply encrypt existing data with the new hash. The other systems will not know the old password to load it into memory to encrypt it with the updated hash.

Canela has come up with a solution that should solve all of the issues presented. The goal is to release an update as soon as possible. The solution is straightforward but nontrivial to implement.

-Mark
  Reply
#7
(07-07-2021, 09:21 PM)mark_talluto Wrote: I did not realize that we did not document cdb_forgotUserAccountPassword. We'll get to work on that today.
cdb_forgotUserAccountPassword is useful for cloud data.


Hi Mark - as far as i can see there is no cdb_forgotUserAccountPassword command, or at least there is no autocomplete for this.

The only indication that cdbi_forgotUserAccountPassword exists was your helpful forum post on the topic - looks like an internal method that hasn't been exposed to a pubic API ?
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)