Custom email verification – cannot set emailVerified

Question

I'm trying to implement custom email verification for user sign up. The default one only sends plain text messages, but we want to send HTML formatted ones.

The current approach:

1. Using Cloud Code, a function Parse.Cloud.beforeSave("Parse.User"… sets a generated token in the user's 'confirmationToken' field
2. The same function sends a formatted email using MailChimp's Mandrill Cloud Module service to the user, including a confirmation link with the confirmationToken like this http://www.our-website.com/confirm_email.php?confirmationToken=confirmationToken
3. The User clicks on the link, our website gets the token through a HTTP GET request
4. The website runs Parse PHP SDK and queries the user database to get the user with the confirmationToken field's value that matches the token from the request
5. If the user is found, we attempt to set the emailVerified field to true…

Now here's the problem. The emailVerified field seems to be protected. Trying to set it will give you a ParseException 'InvalidKeyName' (105). Now, I could just use another field, but the problem is that we had set up the default Parse email verification previously, and our apps are looking for that value in emailVerified. Users already signed up with the default email verification, and we cannot just change it because the apps are deployed.

Is there any way we can set the emailVerified field? Can anyone think of a solution that will also work for apps that are already checking for this field, even though in the future we'd have to set another one? Is the field still protected if you disable email verification (right now it is still enabled)?

Any help is greatly appreciated.

Answer 1

Unfortunately, the emailVerified attribute cannot be set, even using the master key. The only alternative is to create a custom verified attribute to go along with the custom verification logic.

The approach I'd take would be this:

1. build and test the new scheme, using the new field
2. run a migration that populates the new attribute with the users' emailVerified
3. invoke that same logic in afterSave for any Parse.User
4. revise the client to check the new attribute

I realize that step 4. violates a premise of the question, but your app must designed under the premise that the client can and will be revised. If its not this issue, it will be another. Operating conditions will change, and so must your client.