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 request:
As part of the email verification and password reset improvements in Parse Server 8, the queries used for these operations have changed to use tokens instead of username/email fields. To ensure optimal query performance, Parse Server now automatically creates indexes on the following fields during server initialization:
_User._email_verify_token: used for email verification queries_User._perishable_token: used for password reset queries
These indexes are created automatically when Parse Server starts, similar to how indexes for username and email fields are created. No manual intervention is required.
Warning
If you have a large existing user base, the index creation may take some time during the first server startup after upgrading to Parse Server 8. The server logs will indicate when index creation is complete or if any errors occur. If you have any concerns regarding a potential database performance impact during index creation, you could create these indexes manually in a controlled procedure before upgrading Parse Server.
Related pull request: