Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented email sending logic including forgot password, and email verification #187

Closed

Conversation

taylorstine
Copy link
Contributor

This is an attempt to remove this todo

This will handle email password reset and email verifications.

Note that this adds views to parse-server, to provide a default implementation of the webpage that validates an email, or resets a password. A user can override this default implementation in their express app. (side note, notice the references on some image assets to parse.com. Not sure if this is ok or not).

This adds a new optional configuration parameter emailSender, which is given all of the information needed to send one of the verification emails.

Here's what my implementation looks like

@gfosco
Copy link
Contributor

gfosco commented Feb 2, 2016

This is very cool. Awesome work, @taylorstine. I request that others to take a look at this and comment. It does not include a default emailSender?

@taylorstine
Copy link
Contributor Author

@gfosco No, I figured the documentation may have to be updated or something to show an example implementation. I can easily add one, but I just figured the implementation of sendEmail would vary, since it depends on the service being used (in my case AWS-SES).

A default implementation could use SES, it would just require some configuration in the AWS Cloud Console from the implementer.

Also, unless parse is still open to hosting a no-reply@parse.com email, we would also need the email address from which to send the emails

@gfosco
Copy link
Contributor

gfosco commented Feb 2, 2016

Because of our previous module support, I'd like to see the default be a Mailgun or Mandrill implementation, but I guess we could always add that later.

@taylorstine
Copy link
Contributor Author

Cool, I'll look in to that. I've never used those before so I'll have to do some investigation.

@jamiechapman
Copy link

This looks pretty sweet, odd timing too as I just submitted a pull request with support for a MailAdapter and Mailgun (#191), maybe we could bridge the two together?

@taylorstine
Copy link
Contributor Author

@jamiechapman that sounds good. @gfosco would you rather we implement this now, or would you prefer the default implementation in a separate PR?

@gfosco
Copy link
Contributor

gfosco commented Feb 3, 2016

@taylorstine I'd like to accept @jamiechapman 's MailAdapter method. Are you okay with implementing SES through that?

@lucianmat
Copy link

👍 great job

@doender
Copy link

doender commented Feb 3, 2016

Great work @taylorstine and @jamiechapman!

@taylorstine
Copy link
Contributor Author

@gfosco 👍 I'm not sure if this is what we're talking about doing, but I think the best thing to do might be to allow a user to specify a sendEmail function (though it should be renamed) if they want to optionally send a customized email. If no sendEmail method is passed @jamiechapman MailAdapter would be used to send a more generic email, the way parse currently works, with just some text and a link.

@jamiechapman
Copy link

@taylorstine definitely! Maybe we could take some inspiration from the Parse.Push JS SDK and implement something like Parse.Mail.send({...}), which as you can say would then be useful to send messages via other functions etc.

@taylorstine
Copy link
Contributor Author

@jamiechapman I like that idea, where the user could specify options and based on those options we decide how to route the sending logic. The payload to send could be something like

{
  mailType: "VERIFY_EMAIL"
  links: {verify: "http://www.example.com/verify"}
  recipient: "joe@example.com"
  subject: "Verify your email"
  text: "You are being asked to verify your email, click here http://www.example.com/verify"
}

And the user could specify a middleware type function to modify these parameters, with the default as a function that just returns this payload.

@facebook-github-bot
Copy link

@taylorstine updated the pull request.

@drew-gross
Copy link
Contributor

Lets consolidate discussion in #275

montymxb pushed a commit to montymxb/parse-server that referenced this pull request Feb 14, 2016
Increasing code coverage, fix comments and define static type of the PaseSchema
@gfosco gfosco mentioned this pull request Feb 20, 2016
@gfosco
Copy link
Contributor

gfosco commented Feb 26, 2016

Closing this, looks like the eventual solution will come from issue 275.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants