This document only highlights specific changes that require a longer explanation. For a full list of changes in Parse Server 8 please refer to the changelog.
In order to remove sensitive information (PII) from technical logs, the Parse.User.username
field has been removed from the email verification process. This means the username will no longer be used and the already existing verification token, that is internal to Parse Server and associated with the user, will be used instead. This makes use of the fact that an expired verification token is not deleted from the database by Parse Server, despite being expired, and can therefore be used to identify a user.
This change affects how verification emails with expired tokens are handled. When opening a verification link that contains an expired token, the page that the user is redirected to will no longer provide the username
as a URL query parameter. Instead, the URL query parameter token
will be provided.
The request to re-send a verification email changed to sending a POST
request to the endpoint /resend_verification_email
with token
in the body, instead of username
. If you have customized the HTML pages for email verification either for the PagesRouter
in /public/
or the deprecated PublicAPIRouter
in /public_html/
, you need to adapt the form request in your custom pages. See the example pages in these aforementioned directories for how the forms must be set up.
Warning
An expired verification token is not automatically deleted from the database by Parse Server even though it has expired. If you have implemented a custom clean-up logic that removes expired tokens, this will break the form request to re-send a verification email as the expired token won't be found and cannot be associated with any user. In that case you'll have to implement your custom process to re-send a verification email.
Important
Parse Server does not keep a history of verification tokens but only stores the most recently generated verification token in the database. Every time Parse Server generates a new verification token, the currently stored token is replaced. If a user opens a link with an expired token, and that token has already been replaced in the database, Parse Server cannot associate the expired token with any user. In this case, another way has to be offered to the user to re-send a verification email. To mitigate this issue, set the Parse Server option emailVerifyTokenReuseIfValid: true
and set emailVerifyTokenValidityDuration
to a longer duration, which ensures that the currently stored verification token is not replaced too soon.
Related pull requests: