make intended url redirect logic auth guard aware

[GigaGiorgadze]

Hello, I ran into an issue when using multiple guards — a user trying to access a page protected by the super_admin guard would, after logging in via the web guard, get redirected to the super_admin login page instead of their intended destination.

I've seen this same problem across several multi-guard apps, so I thought making the intended URL logic guard-aware at the framework level would be a clean fix. I resolved it in my own apps with a manual check, but it feels like something the framework should handle.

This stores intended URLs per guard ({guard}.url.intended) instead of a single url.intended key.

Thank you.

[rodrigopedra]

This would be a breaking change for anyone using the raw url.intended session key to manipulate the intended URL.

[GigaGiorgadze]

This would be a breaking change for anyone using the raw url.intended session key to manipulate the intended URL.

considering there are helpers for it i think that rare but i understand the concern, should i move PR to next major release then?

[rodrigopedra]

You can wait for a maintainer's input.

I like the idea, and this specific use case had bitten me in the past.

But I also saw a project that resorted to manipulating it directly, as the intended URL is automatically set by middleware, and it wanted to override it for a change password screen and keep it between screen refreshes.

It was a very niche case, and while I didn't look into changing it (I was working on something else on this project), it is something I saw in the wild.

[taylorotwell]

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!