Passwordless | Reset password with passcodes handle case for non-existent users #2915
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this change?
In #2852 we implemented passcodes for reset password for some "ACTIVE" users. Namely the ones with both the "password" and "email" authenticator, and users with just the "email" authenticator.
In #2889 we implemented passcode for reset password for the remaining active users, i.e the ones with only the "password" authenticator.
And in #2902 we implemented passcode for reset password for existing users in the non-ACTIVE state.
There is one more group of users that could go through the reset password process, and these are users who currently don't have a Guardian account.
To prevent username enumeration, the behaviour in the UI has to be the same as for all the other user states. Specifically we have to show the
/reset-password/email-sent
page, with a passcode input box.Since these are non-existent users, we cannot send an email to them for obvious reasons. So in this PR we've taken the same approach that is used for the existing legacy reset password pages, i.e we just show the email sent page and in our additional information box we include our
noAccountInfo
messaging. This messaging says that if you don't receive an email within two minutes, then you likely don't have an account, and includes a link to create one.The cypress test I've added in this PR covers this behaviour.
We also modify the way we set the
EncryptedState
cookie in this PR. This is because this cookie can get quite large, and in some cases could exceed the maximum size of what was allowed in theCookie
header (only noticed on DEV and CODE).So we remove undefined keys and values, to reduce the size slightly.
The bigger change was finding out that the Okta IDX API
stateHandle
is 817 characters in length! But it turns out we don't need to persist the entirestateHandle
in the Encrypted State.In fact all we need is the first 46 characters (before the
~
). This is actually the same bit that is required for thestateToken
parameter in the/login/token/redirect
endpoint used after authentication, see for more contextgateway/src/server/lib/okta/idx/shared/idxFetch.ts
Line 128 in 34311cd
and
gateway/src/server/lib/okta/openid-connect.ts
Line 39 in 34311cd
for more context.
The IDX API seems to work with only that bit (tested with Hoppscotch). So we don't actually need to persist the other 774 characters, and having the cypress tests pass provide us with confidence that this change works.
Tested
Future options
While this PR doesn't send an email to users, we could work with Data Privacy and other teams to figure out if we can send users an email, for example letting users know that they don't currently have an account, or potentially even creating an account for users if they go through the reset password flow.