User Password Not Set Upon Successful Registration when Passwordless Login is Enabled

[nathanoday]

We are experiencing strange behavior with the self-registration form component.

Expected Behavior:

1. When someone successfully completes the self registration form, with email verification code enabled, they are automatically logged in upon submitting the verification code.
2. After logging out and then logging in with their password setup during registration, they should be able to do so.

Current Incorrect Behavior:

• Part 1 above works correctly, as the "Enable Passwordless Login" setting is enabled and configured correctly.
• However, upon logging out and attempting to log back in, the password is rejected, even when it is confirmed to be correct.

Observations about Error:

• The experience cloud registration log (which is enabled and working correctly) shows that the password was captured correctly on the registration form.
• The User.LastPasswordChangeDate field on the newly created experience cloud user is null, implying that the password has never been set.
• This must mean that the user was only able to login successfully the very first time as part of registration because of the "Enable Passwordless Login" feature.
• If a user follows the "Reset Password" procedure, they can successfully set and use a new password from then on.
• This is occurring for all new site users.

Does anyone know why the password is being correctly captured from the registration form but not set on the User that gets created?

[jlowe-SFDC]

@nathanoday - apologies for the delay. Not getting notifications through for the repo. I've added a similar response to your Trailhead post.

Based on what you have provided above, it sounds like you haven't configured login to use the passwordless features. In the package, there is a custom login component which has an equivalent setup to enable passwordless login here too. So when you enter your email or phone number, it will send a code to login.

When using either component you would configure them in the custom metadata to hide the Password/confirm password fields as they not used for this type of setup. On my ever show the fields for email or phone number and country code.

The process to get this working correctly is to register with the self reg custom component configured using passwordless mode with email or sms to receive a code. Enter that into the verification code screen, and it should successfully register. Upon login, use the same email or SMS as previously used to register and the verification process happens again with a new code which will log you in.

Let me know if this doesn't work and I can investigate further. FYI, at this time, there is no component included to register a new device/de register an old one. It can be done, but is not currently implemented. It’s on my roadmap though.

[jlowe-SFDC]

Looking further at this @nathanoday, the code uses the UserManagement class with the initSelfRegistration() method which accepts two params - AuthMethod and user. The AuthMethod is currently set in the code (see below snippet) to either SMS or EMAIL which looking at the docs are the only supported methods when self-registering.

When you login using the Custom Login component, there is a call to verifyPasswordlessLogin() which is paired with initSelfRegistration(). It also accepts SMS or EMAIL as the AuthMethod, and the component queries for an Active user to login matching the provided email or phone number.

I suspect that the Salesforce backend processing based on the above method call just doesn't set the password on the user even if it is provided on the form when using these methods but I can't be sure as that is hidden by the product.

See: https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_UserManagement.htm#apex_System_UserManagement_initSelfRegistration

To conclude, I think what you need to register a password as well as a mobile number to login can be done but is not actually implemented at the moment as a feature. It requires a new component which is only available to logged in users and has calls to the methods:

• registerVerificationMethod()
• verifyVerificationMethod()
  This will allow a way to add a password after initial registration with passwordless as an option. There would need to be further changes to the login component to support logging in with different methods if you have registered with multiple methods.

Based on this, I won't close the issue. But I will tag is a 'RoadMap' for a future release. I would suggest that you review the configuration for your existing setup in the mean time to hide the password field so it can be used based on the current functionality.

[nathanoday]

Thanks, @jlowe-SFDC ! Going to put a more technically detailed response here in response to your comments compared to my higher level Trailhead post response. So, we do have passwordless login enabled right now with email verification, and that's working great. The part that confused us is that, because our implementation partner also included a password field on the registration form and it's being validated / required, the assumption was that the password would also be set on their account.

The login form does not have passwordless login enabled (unlike the registration form, which does), meaning the only option for someone to log back in after their first session is to use the forgot password option and set it again.

Since the reason we decided to use the email verification code was to create a second factor for authentication on top of the email (but only for account creation), and that's not possible right now, it sounds like it would be better to disable passwordless login and simply use password for registration and login until this package can be developed to support this use case. Would you agree?

[jlowe-SFDC]

That makes sense what you are trying to do. It actually sounds like what you need is the built in functionality for MFA: https://help.salesforce.com/s/articleView?id=xcloud.mfa_direct_login_user_perm.htm&type=5. So, using this component (or even the standard one I think) you could set a password initially and then with this permission Experience Cloud would automatically redirect you to the MFA screen to add that 2nd device. If you want to do this via SMS, it needs another licence https://help.salesforce.com/s/articleView?id=xcloud.security_mfa_sms_for_external_users.htm&type=5 but the other methods are availalble out of the box I believe.

The benefit of this component is that the initial step to identify an existing contact in the system by a custom query might be useful to you. If these are internal staff, create them as a Contact and then use a query in the documentation to find them. The component will then create the experience cloud user and register them for the site. The out of the box component will just blanket create a new contact without checking first. So I'd actually base your decision on this use case and then setup the other Permission Sets accordingly.

Based on your explanation, my initial thinking of the new functionality isn't actually needed!

[nathanoday]

Hi @jlowe-SFDC, thanks for pointing me in this direction, I appreciate knowing that Salesforce has a built in MFA feature. We are using Person Accounts, and the existing Person Account matching feature is definitely one of the reasons we went with this component; sounds like we just need to turn off passwordless login, and use the standard email verification code functionality provided by Salesforce as you described. Will take a look; thanks!