Verification Emails are triggered every time User.current is saved

[dblythy]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and the Parse Swift SDK.

Issue Description

Parse Swift triggers email verification whenever User.current?.save is called.

Steps to reproduce

1. Turn verifyUserEmails on.
2. Update any field on User.current
3. Check emails

Actual Outcome

Emails are sent every time user is updated

Expected Outcome

Emails to only send on #, or email update, as per the SDK.

Specifically, the issue seems to be related to here o the server:

RestWrite.prototype._validateEmail = function () {
 if (!this.data.email || this.data.email.__op === 'Delete') {
    return Promise.resolve();
  } 

For the JS SDK, this.data.email is undefined on any update. For Parse Swift calls, this.data.email is passed.

Environment

Client

• Parse Swift SDK version: 1.9.10
• Xcode version: 10.15.7
• Operating system (iOS, macOS, watchOS, etc.): iOS
• Operating system version: 14.3

Server

• Parse Server version: Master (around 4.5.0
• Operating system: macOS
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): local

Database

• System (MongoDB or Postgres): mongoDB
• Database version: 4.4
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): Atlas

Logs

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[cbaker6]

In the JS SDK, are you able to show where the following occurs:

For the JS SDK, this.data.email is undefined on any update

That will provide some guidance on where this is happening on the client level, or if the server is actually handling it.

[dblythy]

I'm probably not familiar enough with the JS SDK to point where exactly it happens, but my understanding is that object.set(key) add the key to a list of pending OPS, which is then sent to the server, and these specific keys are set. I detected this by console.logging this.data in RestWrite.js. As far as I can tell in my PR, Parse Swift sends the whole body to the server.

I would assume it's _getSaveJSON, which determines what JSON objects need to be sent to the server, only if they have been mutated.

[dblythy]

Another way to replicate this is to have a simple beforeSave trigger on Parse.User, and log object.dirtyKeys(). Even with the code User.current?.save{ result in }, dirtyKeys is the entire struct for Parse Swift. Unless operaton?.save{ is used, which seems to only set the proper key.

[cbaker6]

I would assume it's _getSaveJSON, which determines what JSON objects need to be sent to the server, only if they have been mutated.

I see, this may be the reason. Since ParseSwift uses structs it doesn't have getters/setters and doesn't have a notion of dirty. If the PR I just openned doesn't work, I think I may have a solution.

[dblythy]

Thank you for your help @cbaker6, it is much appreciated.

The issue still occurs on that branch too.

emailVerified isn't showing up in either master or this branch as a dirtyKey, the dirtyKeys are set as 'username', 'email', 'firstName', 'lastName', 'ACL'.

I'm assuming the emailVerified is being triggered by server thinking email is being changed

[dblythy]

Some alternative options to make sure dirtyKeys is passed properly:

1. a cloud function that reverts database ops if original.get(key) === object.get(key)
2. special internal handling for ParseSwift to manage these dirtykeys

Option 1 would require every class which is used in Parse Swift to have a beforeSave trigger. Option 2 would require server changes and no Parse Swift changes.

[cbaker6]

@dblythy thanks for reporting! I believe the linked PR fixes the issue you found.