An Action+Route to send the verification email again after expiration

[adazmy]

Just a side note about why there is no action or route inside the expiration error message to ask for a new verification email?

thanks!

[Tubusy]

Yes, I've totally failed in trying to create a 'send new verification email' action. Is there an example of how it would be done? I am surprised it is not a part of the bundle as it will always be essential to have one.

[adazmy]

If you follow the fact that a user should be logged in to verify his email (debate en #27), then just catch an additionnal ExpiredSignatureException from $this->emailVerifier->handleEmailConfirmation($request, $user); and resend the mail using the code from register (you can add a different flash message).

if you added the email on the URL ( suggestion on #31), get the user object from the email, and resend the mail using the code from register.

[Tubusy]

Oh I see, it is as simple as ending a new email. Clever. I was overthinking it. Thanks @adazmy

[adazmy]

But still... this should be (in my opinion) implemented directly by the bundle... and maybe have it's own action/route if we want to add this in a message.
Waiting for the creators to react :)

[jrushlow]

Good Morning! Off the top of my head, this is a feature that would be best implemented in the Maker Bundle code. Technically it is possible currently with a little bit of leg work. I'll review the code bases and see how to best implement this over in Maker Bundle.

[lukepass]

This feature would be useful too!

[vincentcox]

@jrushlow , Hi there!
Any idea how to properly implement this? Apart from the controller/twig template that shows this page, and running the function that resends this mail with a new token, there needs to be a check that only allows to send this mail after let's say 2 hours or max 1 mail/hour/user. Otherwise someone can register in your application and fill the mailbox of this user with 100's of verify email links. I saw this happen several times at clients when performing security testing.

The main issue (a consequence of not using database entries) is that there is no way to keep track of that without making database entries. So I think some code from the "password reset" package needs to be used in this package to make this work. The symfonycasts password reset package also uses a table dedicated to keep track of that and fix the concern above.

Let me know what you think!

[ToshY]

I second @vincentcox's idea. The password reset bundle already has most of the logic (and config) which could be used here as well.

[arirangz]

Hi there!
Any update on adding this feature in the bundle?

Thanks

[ToshY]

@jrushlow It's been quite some time since there was an update on this issue. Could you give as some additional information on what the status is? Is this feature still going to be implemented here / Maker bundle one day? Or should we just implement a workaround ourselves?

[ToshY]

Good Morning! Off the top of my head, this is a feature that would be best implemented in the Maker Bundle code. Technically it is possible currently with a little bit of leg work. I'll review the code bases and see how to best implement this over in Maker Bundle.

@jrushlow It's been well over a year since you've mentioned in #50 that the functionality was "currently planned". Could you please give us a status update?

[weaverryan]

I’d welcome a PR to MakerBundle to generate this and/or any potential helper code in this bundle that would make it easier :)

[arirangz]

hello !
any news about this feature?
Thanks