401 Unauthorized

[daniyals]

I did a setup as mentioned in the readme, it works fine on local, but when i deploy on production, it gives a 401 Unauthorised error on

/magic-url/1?expires=1661899121&redirect_to=portal&user_type=app-models-user&signature=xxx

[innoflash]

Did you use the correct APP URL on your .env?

[hipoagencia]

Same here!

[zawilliams]

Also having the same issue - actually not working locally. Just getting a 401 as well. I have APP_URL set in my .env.

Any thoughts on anything obvious I might be missing? I also set the model to a different namespace App\Models\User.

[hipoagencia]

Also having the same issue - actually not working locally. Just getting a 401 as well. I have APP_URL set in my .env.

Any thoughts on anything obvious I might be missing? I also set the model to a different namespace App\Models\User.

i'm sorry.. i cant remember what i've done to make it work. But, i will try to remember and i come back here. It was a stupid thing.

[zawilliams]

@hipoagencia thanks for taking some time to think through. I'm at a loss here haha.

[zawilliams]

Ok, so I removed the setRedirectUrl() method call and it works:

$generator = new LoginUrl($user);
// $generator->setRedirectUrl('/account');
$url = $generator->generate();

Any thoughts on why this would be the case?

[zawilliams]

I've also noticed that the URL defaults to 0.0.0.0 with my docker setup instead of APP_URL. Not sure if that is a separate problem with Docker or not.

[tobz-nz]

I was having the same issue, but sorted it out.

I'm using docker (laravel sail) with nginx & ssl and was using URL::forceScheme('https'); to get urls to generate with https. This is not the right way to do it.

The right way is to update app/Http/Middleware/TrustProxies.php: (should probably set real IP's but 🤷‍♂️)

protected $proxies = '*';

after making this change, the signed urls are generated properly.

[salmanjaveed]

Facing the 401 unauthorized error now, it was working well until it isn't working. This is the generated url:

https://domain.com/autologin/178?expires=1725295696&redirect_to=%2Ftasks%2Frun%2F518&user_type=app-models-user&signature=xxxx

In localhost it logs a user in, but redirects to '/' instead of to the redirect route and in production keep getting the 401 - unauthorized error.

Any ideas or help is highly appreciated.

[rodrigopv]

Hi there,

We’re participating in a hackathon, and we were on the verge of tears because the magic link authorization wouldn’t work in production.

Our production website is deployed using Coolify, with an Nginx proxy and Traefik on top. On Cloudflare, we had Strict SSL enabled to ensure that only HTTPS traffic flows between Cloudflare and Traefik.

The first step towards fixing the issue was to disable forceScheme. Disabling it allowed us to uncover the real problem behind URL generation. However, after disabling forceScheme, mixed content began to appear, breaking the entire app instead of just causing the 401 error during authentication.

We explored different solutions for configuring trusted proxies, including one that fetched Cloudflare IP addresses to build the allow list dynamically.

The key issue that we overlooked from the beginning was how the trusted proxies setup works. Trusted proxies allow specific HTTP headers (e.g., X-Forwarded-For and X-Forwarded-Proto) to override URL generation based on the protocol used in the outer proxy (in this case, HTTPS).

To debug, we went into the container and created a public script to check the phpinfo() output. It’s crucial to check the phpinfo() output using an HTTP request, not through the CLI.

Our problem was that the first proxy (Nginx, in our Nixpacks setup) was not forwarding the correct HTTP headers from the outer proxy, which originated from Cloudflare.

If the X-Forwarded-Proto header doesn’t reach PHP, the trusted proxy setup won’t work. To fix this, we added the following lines to our Nginx configuration to ensure all necessary HTTP headers are forwarded:

proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

With this configuration, phpinfo() began showing https in the X-Forwarded-Proto header. Afterward, we set up the trusted proxies with the correct IP addresses. In our case, the incoming IP address was Traefik’s, not a Cloudflare IP. This meant that when we initially added the Nginx configuration but continued using the Cloudflare middleware, it still didn’t work.

Key takeaways (TL;DR):

1. Ensure your proxy forwards the necessary headers (e.g., X-Forwarded-Proto) to PHP.
2. Verify the setup by creating a temporary public script to call phpinfo().
3. Use the phpinfo() output to identify the request’s source IP addresses, and configure your trusted proxies accordingly. If security is not a concern, you can use '*' as documented in the Laravel 11.x guide.
4. After completing the setup, mixed content issues should disappear without needing forceScheme, and your magic links should work without triggering 401 errors.

We were ready to abandon our entire Coolify setup to bypass this problem, but after giving it a fifth try, we finally identified the root cause.