Need to add email verification

[mstfblci]

Is your feature request related to a problem?

No

What do we currently have to do now?

No response

Describe the solution you'd like

MustVerifyEmail class add to User model, Email Verification Template and Middleware

Describe alternatives you've considered

No response

Would this be a breaking change ?

• [ ] Yes

Anything else ?

No response

[os-nikita]

For reference, Laravel have a great DX for this: https://laravel.com/docs/9.x/verification

I may take a crack at starting a PR next week for this, useful for what we're working on.

[josephmancuso]

Thanks. I don't like the way we did it in 3.0 which is why I never brought that feature over to 4.x

[os-nikita]

What didn't you like about your previous implementation? Useful to keep the lessons learned, if you don't mind sharing.

[josephmancuso]

I think we had like email sending inside the model, verifying was done against the model when it prob should have been done in a middleware. I don't remember exactly how it was done but I didn't really like it. Just very clunky. Most of the logic was done inside the scaffolded controllers which prevents us from updating any issues, etc.

We'll have to flesh this idea out a bit and detail each step of the flow to make sure this works for M4.

[os-nikita]

Thanks for that.

I've just implemented and deployed email verification today so can provide a high level overview of what I did:

• Middleware: EmailMustBeVerified - looks at verified_at and redirects to a view (below)
• View: explains that the user needs to confirm their email before proceeding and offers a button to re-send the confirmation email
• Action/Service: sends a mailable to the user; this action is triggered by 1) the end of the registration process and 2) manually by the user in the view above (in a controller)
• Mailable: standard stuff, but I also created an html email template, which I think is handy for a framework like Masonite to have
• Token: I used from cryptography.fernet import Fernet to encrypt the user id for the confirmation link. This removes the need to send the user id in plain text in the url. Some devs prefer to hide user ids whether for security or business purposes.
• Routes: display the view and handle the confirmation link (the latter decrypting the token with Fernet and using the user id to log in`
• Security: if the user is already verified when the confirmation link is accessed, the current user is logged out and redirected to login. As a precaution for re-use of the confirmation link. A more robust solution would be to store the confirmation tokens.