I've built a simple application that works just fine but uncovered a bug not sure how to tackle. I am using the typical Laravel session login so for this situation assumed I am logged into a laravel app.
This app also sends email notifications with links sending the user to a specific page within the app (login protected).
This is what happens during my test and not sure how to fix it:
This opens a new tab in my browser and gives me the "403 This action is unauthorized." for that URL. I then refresh the original page that works and it now shows "403 This action is unauthorized."
So it looks like when opening a new tab, it kills the current session instead of using it. Any idea on what to do?
Thanks. There is no parameters. I sent the link to myself, clicked it and it happened again. For whatever reason, it's starting a new session because it can't find the original one (I still see it accessible whether I use file, cookie, database session storage)
If I breakpoint on Illuminate\Auth\Middleware\Authorize@handle the authorize statement returns true after logging in, but when I click the link in email, it returns null.
Here's some more info on the error. It stopped killing the session when I changed config/session.phphttp_only from true to false.
I am not sure why that's causing an issue, but the URL being generated is an HTTPS URL in the email. Exactly like it is when I open it successfully manually.
I am going to push this code change to production and see if it really solves the issue.
UPDATE: This did not fix the issue in production; it only started working fine in local dev. The only difference should be the HTTPS cert.
Agreed, it's very confusing especially since the issue doesn't happen when I disable http_only. Need to test same code on a different host now. I am using nginx on RedHat.
It worked locally in dev but not in production. Production is a HIPAA compliant environment, so I am starting to wonder if there is something being stripped out in the request/response causing this issue.
When you click the link in the email, presumably the same browser is opened that you already have open on this site? The browser should present its still valid session cookie for that domain to the server and the server should find an active session and reuse it.
open your browser network tools and check what is sent, and if any redirects happen.
There is a mailgun (from rackspace) generated link that does a 302 redirect to the expected URL. It's the typical tracking URL. I have disabled click tracking for now on mailgun just to make sure, but would be surprised if rackspace was causing this.
Other than that, there's nothing else happening on click.
Make sure your session.php is configured with "same_site" => "lax" instead of "strict": your email provider has a different domain, so in strict mode your app will refuse its cookies (in GET, it still refuses cookies in POST using "lax").
I had issue: on link click (in smartsheet/google sheet) session values from GET is missing.
But when I copy/paste same link from (sheet) to browser - session works as should. Also click on same link from Email (thunderbird) was working correctly.
Thank you @spotlightd for that comment. This was happening to me. It was driving me absolutely nuts trying to solve this. Adjusting 'same_site' to 'lax' did also solve this issue for me.
I am running into the same issue with outlook web. However I found that outlook is adding this in the header when you click the link: -strict-origin-when-cross-origin. I believe this is what is causing the issue. I still haven't found a solution.