Can Principal.uid change?

[Former Member]

Hi,

I want to implement a registration mechanism, where my new users must enter their e-mail address and a password. Principal.uid will hold the username (i.e e-mail address) by default.

Now, the user may change her e-mail address later on, and we must adapt and accept her new e-mail address during subsequent login attempts. In other words, we must override the value stored in Principal.uid as that is the field user for letter the user log in. Is it safe to do so? Are there many objects that refer to this attribute? Afaik, it's the value of UID that's used during login, we my application is kinda sensitive to any changes in UID.

Can you confirm that it's a viable approach to handle e-mail changes? What references to UID should i be aware of and handle properly?

Thanks!

[soulus]

Hi Gabor,

Generally there is a method to do that in OOTB hybris (at least at hybris 5.7+) - de.hybris.platform.commercefacades.customer.CustomerFacade#changeUid

Works pretty fine, taking care of the password re-hashing and all the related stuff. Unless you have something project-specific & relying on that field - shall be fine to use it.

Though you may want to add additional security-levels, like storing the list of the previous emails, in case someone steals the customer's email and changes it in account, or to be able to find him in payment history of your payment provider... but to what extent you want to get paranoid - completely depends on your project's specifics, generally that is not required.

As of the implementation we had - did not have any problems with using that method, no additional customization that we required

[Former Member]

Thanks for this answer, quite detailed!

Before accepting it as THE answer, i have one more question: I saw that BruteForceLoginAttempts relied on Principal.uid. What will happen with those records that are referring to a UID that we're just about to replace with another one? After the change, they may point to either a non-existing user or a different one.

Thanks!

[soulus]

Though there is nothing about this in hybris wiki (and this was something new added in hybris 6.0 or later) - i guess your you may be right about that. Yet i'd say this is a pretty edge case, which generally should really rarely exist. Why?

1. If the user was able to login to "free" some email - his counter should be reset to 0, and that will make it OK if another user one day will use that email.

2. If it is not 0 - then it generally means that this UID is "busy", and user cannot change his uid to this one, which is pretty fine

following in the second comment

[soulus]

3) If you allow CS Cockpit user to make those changes - then, perhaps, you will need to add some service to clean up those attempts on UID change, which is generally not needed for the other scenarios

[soulus]

4) If you allow to delete users (this may be required, say, to be aligned with some governmental user-data related policies which allow user to ask you to delete all his account from your site) - you may as well add some interceptor to clean up the counters.

Generally, i believe, cases 3&4 are pretty rare, and it is mostly up to customer to decide whether he wants to spend money developing those or to teach his CS team to handle such cases