Impersonate is working perfectly on local, but logs user out on production

[nickolasjadams]

On my localhost, I've had no issues at all. I can impersonate users as expected.

Now that I'm on production and really need it though, I click my impersonate link which uses the routes for take/{id} And it does a 302 redirect from take/{id} to the correct page projects. But then it does another 302 redirect back to the login page.

Nothing was written to my logs.

Any ideas why it's doing this. Or why might it be doing this on my production server?

[drbyte]

But then it does another 302 redirect back to the login page.

Usually a redirect to login means the user wasn't authorized to access the resource at that URL. (ie: \App\Http\Middleware\Authenticate middleware).

So if all the application code is truly identical in both places, you may need to look into configuration differences between local and production in the areas of sessions, cookies, and other environmental factors.

... and/or dig into the code that this package uses to do the impersonation, and dd() various things until you figure out where the authentication is failing (ie: did it actually pass the right impersonation id, did the canBeImpersonated and other functions it relies on pass correctly, did session data get set right, did cookies get set right, what about the auth failed such as was it the user or something about the resource (controller/page/url/etc) that was rejecting it, does disabling any certain middleware make it all work fine, is there anything missing about roles/permissions that you have created but maybe not assigned in prod, etc).

If you're writing tests for this area of your code, perhaps there's a situation you've not written tests for yet, like another angle or contributing factor not considered in the tests.

Those are just a bunch of thoughts to hopefully help in your investigation...

[nickolasjadams]

But then it does another 302 redirect back to the login page.

Usually a redirect to login means the user wasn't authorized to access the resource at that URL. (ie: \App\Http\Middleware\Authenticate middleware).

So if all the application code is truly identical in both places, you may need to look into configuration differences between local and production in the areas of sessions, cookies, and other environmental factors.

... and/or dig into the code that this package uses to do the impersonation, and dd() various things until you figure out where the authentication is failing (ie: did it actually pass the right impersonation id, did the canBeImpersonated and other functions it relies on pass correctly, did session data get set right, did cookies get set right, what about the auth failed such as was it the user or something about the resource (controller/page/url/etc) that was rejecting it, does disabling any certain middleware make it all work fine, is there anything missing about roles/permissions that you have created but maybe not assigned in prod, etc).

If you're writing tests for this area of your code, perhaps there's a situation you've not written tests for yet, like another angle or contributing factor not considered in the tests.

Those are just a bunch of thoughts to hopefully help in your investigation...

Thank you for your suggestions @drbyte ! I appreciate it.

I found that when typing the urls out instead of hitting my buttons, that impersonation did work. Well kind of. It would log me out afterwards. #162 had a workaround in it that ended up being a solution though.

[tonypartridger]

I used similar and set the password for web and sanctum as different routes different guards and all was good.