Level 39
First thing I should do is to have a look in your logs (storage/log/laravel.log)
May 28, 2021
5
Level 1
Email Verify 302 Redirect to Login Infinite Loop
Hi All!
I'm having an issue enabling the Features::emailVerification() of Fortify in my Jetstream & Inertia based application
I've set the feature on in my fortify[dot]php config and I've ensured that my User model implements MustVerifyEmail
When I protect the routes of my web routes file with verified I end up getting lost into an infinite loop when i attempt to log in
I successfully log in, and am redirected to email/verify upon which I get a 302 response back to login which because I am successfully logged in, redirects me to the home page but because it's protected with verified redirects me to email/verify and so the loop proceeds until Chrome sees the too many redirects and stops the loop for me
I've tried taking the verified option off my routes and this of course allows me to login and browse the pages of my app
But if I manually attempt to visit email/verify I'm redirected back to the login and then back to the home page (because i'm already logged in)
I'm struggling to determine what is going on, as it's all happening at the request level
I've tried disabling each of the middleware active on the web routes, but it either has no effect, or breaks the login to start with
I've tried changing the session driver from redis to cookie, to see if it has something to do with the session, but this has had zero effect
I'm happy to post code snippets but as I have no idea where else to look, I'm not sure what you need to see - just let me know what you need to see and I'll post it
To confirm a few things:
- I'm using Laravel 8,43
- I'm using Jetstream 2,x
- I'm using InertiaJS
- I have an "extended" user model, but this is fundamentally just a few extra fields to the standard User model, and I've updated the Jetstream config to define the model FQN
- I'm using Fortify (standard with Jetstream)
- I'm running on macos but have tried on Linux
- I'm using PHP8
Any advice, thoughts or suggestions would be greatly appreciated
This seems like such a simple thing to have enabled, and I'm positive it'll be something fundamentally stupid, but I just cannot see it
If you need any information from me, please just let me know
Thanks for any help in advance
ps: I've had to use the [dot] as Laracasts won't let me use "links" on my first post and apparently [dot] is enough
Level 1
@sr57 thanks for the reply. I should have stated in my original post that there's nothing being generated in the logs. There are no exceptions being generated, no errors, warning or anything of the sort.
Level 1
A quick followup on additional checks I've made:
I've tried overriding the route entry in the Fortify package routes, but this doesn't seem to do anything.
I then tried commenting out the verification routes in the Fortify package routes file and then checking to see if the routes still exist and they do?! This is suggesting to me that there's some other package/system that's setting the route. Unfortunately artisan just lists it as a Closure so I'm not sure where it's being set? NB. this is the same if I "disable" the Fortify feature.
The final thing I've tried is overwriting the route in my app's web routes file to see if I can get anything to show, and this works - I'm able to see the response without the endless redirect.
This is all leading me to the suspicion that another package is setting the route to a closure somewhere. I've tried doing a search for the route name or the route url but again nothing is coming up.
I did find a lingering Laravel/UI package that was being loaded in, but I've removed this and still no improvement.
If anyone has any suggestions, please let me know. I'll continue to deep dive into this myself and keep you posted of any additional findings.
Level 39
I understood it's a fresh installation with light modification(s)
I suggest now to
- do the same test in a pure fresh installation
and
- reread carefully https://laravel.com/docs/8.x/verification
Level 1
So after some further digging into this, I was on the right path when I said that something else was "overwriting" the routes. Sure enough, I found that a package I'd loaded in composer that had a routes file where these were being set. Strangely, I'm not sure why my "find in all folders" within VSCode didn't find it for me and I had to revert to the command line to find it, but that's a question for another day.
I removed the package and sure enough it works exactly as expected.
In short: if you're having similar issues, search for the route in all the composer packages and find the suspect package that may be overwriting it.
Thanks to @sr57 for replying and for anyone else who reviewed this, thanks as well.
Please or to participate in this conversation.