Account activation using Email and providing a link to resend the email

Hey!

Oh nice idea! I've just prepared a PR with that implementation here:

https://github.com/thedevdojo/wave/pull/170

Feel free to cherry pick the changes and let me know if this works for you!

Once I've got your confirmation that it all works I can merge that into the 2.x branch of the Wave repo.

- Bobby

Hello Bobby.

I will be more than glad to test it and I must admit man that YOU ROCK with the speed of the fix. I was looking into the default changes to apply in breeze to get things happening but you know better than anyone Wave and all the extra changes applied so I am pretty sure it will work.

My idea is that if you register as a client, I will let your account for 24 hours to activate after which a cron job will remove any non-active account allowing it to be re-taken by someone else. But until then, if for whatever reason you need the email re-sent, you can have it as many times as needed and if the 24 hours expired, you will have to start all over by registering and activating the account.

Will keep you posted and thanks again!

Hello Bobby.

So I've tested quickly the functionality and I must say you understood perfectly the need and I am glad that the implementation was really simplified.

I believe there is a point of improvement before it gets merged, as with the current workflow once I try to register and succeed to pass the validation, I am directly redirected to the login page. I would suggest instead to redirect to the new template which will inform me that my account requires activation.

Presently, if I try to visit the route directly (/email/verify) I will be seeing the template with the button to resend my activation email but I won't have an email to the session so I am not sure how will it behave in such case (most likely throw an error).

The improved workflow to me will be:

1. Register as a user
2. If email activation is required, automatically redirect to the account verification template keeping the email in the session
3. If the user verifies his email and succeeds to activate, then the redirect is back to login where they can get into the registered users area.
4. If the user cannot find the email, clicks on the button to have the email resent as many times as required and then continues with the activation.
5. The route to /email/verify should be somehow protected to allow navigation only if the session contains an email with the specific activation flag so that if anyone tries to access it externally or by guessing, won't be able to request an email re-send and cause some app issues as such.

I've tried to override the redirect so that it points directly to your new template, but unfortunately there is a guard or something that still redirects to login form instead of the new email. Get an easy fix for that?

Hey!

Happy to hear that this is mostly working for you!

For the /email/verify only if you first try to login with a valid email address, that is when the route will be available.

If you try to visit /email/verify in an incognito window, then you will be redirected to the /login page, once you fill up the login form and try to login that is when you get redirected to the /email/verify route.

I've just made a minor change so that after a registration the user gets redirected to the email verification route instead of the login route:

https://github.com/thedevdojo/wave/pull/170/files#diff-2762731c1d11df29c17e10e4c6fb7decce50e41313cfa81b44fa6237badf047dL204-R206

Let me know if this works for you in this way!

- Bobby

Hello Bobby.

I've tested your code improvement and yes, it does redirect me to the proper email activation template as needed. For sure I will adapt the template to fit my project design but that is not something expected of the functionality.

I've tested however to navigate to /email/verify in Private Mode on the same browser as well as on another few browsers, but I am still able to navigate to the route and clicking the button does reload the page and send the email over and over again. I believe it will be best to create a small middleware which will protect the route /email/verify and if the session contains a key with a value for 'pending_verification_email' then allow the redirect. This way if there is no key returned to the session, it should not allow the navigation and will redirect back to login page where the user can login and continue.

Something like this should do the trick I guess:

namespace App\Http\Middleware;

use Closure;
use Illuminate\Support\Facades\Session;

class VerifyEmail
{
    public function handle($request, Closure $next)
    {
        if (!Session::has('pending_verification_email')) {
            return redirect()->route('home'); // or any other route that's not protected by this middleware
        }
        return $next($request);
    }
}

And of course, to register the middleware with Kernel and apply it to the route... What you think of that, Bobby? Otherwise everything else worked like a charm, I am just concerned someone would try to abuse intentionally or accidentally reaching the route...

Hey!

Hm, it’s a bit odd that you’re still able to access the /email/verify route since there’s already middleware in place to prevent that. Specifically, this middleware:

https://github.com/thedevdojo/wave/pull/170/files#diff-d5faf1039d205cc666f8b9f1e18364bf84d7439068c734809c77809a41f15810R15

And there's also a redirect condition here:

https://github.com/thedevdojo/wave/pull/170/files#diff-d5faf1039d205cc666f8b9f1e18364bf84d7439068c734809c77809a41f15810R20-R23

The logic checks if the session has a pending_verification_email value before allowing access:

if (!session('pending_verification_email')) {
    return redirect()->route('login');
}

If you’re accessing the route in an incognito window, there shouldn’t be any email in the session, so it should redirect you back to login. The only way you’d be able to access it is if you previously logged in with a valid user in the same session.

I've not been able to reproduce the behaviour that you are describing unfortunately. So what I suspect here is that you have the pending_verification_email session in place which allows you to visit the route.

If you try to log in via an incognito window and don’t close that incognito session, any subsequent incognito tabs or windows you open will share the same session until the entire incognito window is closed. This means that if you logged in or attempted to log in previously within that incognito session, the session data (like pending_verification_email) will persist across new incognito tabs or windows. Only when you close all incognito windows entirely does the session reset. So, if you’re accessing /email/verify within the same incognito session, the session data will still be there, allowing you to reach the route as expected.

- Bobby

Yes, you were perfectly right as such. I believe some browser cache must have been left as after a full browser closing and opening in Private Mode, I got redirected back to the login page (which was the intended and needed way).

Well, on this I can say that the functionality is achieved thanks to you Bobby so if everyone else is OK this can get merged so that anyone that requires an email activation before logging follows the proper workflow and allows the user to request a new email to be sent in case they cannot find it or there was an issue with the server during email sending.

Thanks again, this topic can be considered now resolved.

Hey Bobby, I guess the same thing can be applied to the Fillament version as well, right? As far as the need of a project is to allow user's registrations, there should always be a need for someone to offer the same functions :)

It's been a while since I've tested the Filament improved version on my Windows Host but now that I am settled already in my new office, it is the perfect time to kickstart a new project and see if it all works as it should and if not, share the wisdom/issues with your team.

Hey!

Sounds great, happy to hear that this is all working now. I've merged that PR.

Yep! With the Wave v3 version, this is available out of the box already thanks to the Auth package:

Let me know if anything else pops up!

- Bobby