Good credentials result into api/auth/error instead of forwarding/loading the app

[distributev]

Good credentials result into api/auth/error instead of forwarding/loading the app

[james-d-elliott]

Are you using an official nginx config? This looks like a configuration issue with your proxy. I'd also suggest submitting a HAR file as this can't be replicated and this interaction is tested in integration testing.

[distributev]

In what sense configuration issue with the nginx proxy? nginx doesn't know about authelia URLs, authelia knows so why the nginx proxy configuration would ever redirect to an authelia specific URL like api/auth/error and then, once this part of the URL is manually removed from the browser address bar, the actual application is loaded?

It might be an authelia related (mis)configuration and the authelia configuration is already attached to the case - in addition, even if it is clear that authelia did actually successfully authenticated the user (because, if I manually remove the api/auth/error from the address bar the correct app is loaded) instead of forwarding me to the app it just shows the error screen with the api/auth/error URL. Why would it do that?

I understand this is tested but authelia has so many proxy combinations which supports that testing against each and every proxy with each and every configuration combination (valid) is virtually impossible - Its powerful to support so many proxies but it is also more difficult to be sure what works when. For instance maybe people use Authelia mostly with NGINX proxy manager and I just configure authelia with plain nginx and this combination (maybe) is not so much tested like nginx proxy manager.

[distributev]

If it helps I did use the official authelia documentation for nginx integration and I also looked how swag linuxserver/reverse-proxy-confs is integrating authelia with nginx.

https://github.com/linuxserver/reverse-proxy-confs

[distributev]

I just noticed that, after an expired session, it shows me to login and the URL starts by being
/?rd=https%3A%2F%2Fsubdomain2.subdomain.domain.org%2Fapi%2Fauth%2Ferror

Notice the %2Fapi%2Fauth%2Ferror and the end of the URL => it is redirecting to %2Fapi%2Fauth%2Ferror

this is not what is expected - what is expected is, even after expired session, to provide good credentials and to login to the app and not to see an error screen with an %2Fapi%2Fauth%2Ferror URL after correct credentials are provided

[james-d-elliott]

In what sense configuration issue with the nginx proxy? nginx doesn't know about authelia URLs, authelia knows so why the nginx proxy configuration would ever redirect to an authelia specific URL like api/auth/error and then, once this part of the URL is manually removed from the browser address bar, the actual application is loaded?

None of those URLs you're having issues with are Authelia's URLs. /api/auth/error and /api/auth/_log are not paths we use.

Notice the %2Fapi%2Fauth%2Ferror and the end of the URL => it is redirecting to %2Fapi%2Fauth%2Ferror

I understand what's happening, but it's not Authelia making this redirection or is very unlikely to be. The HAR or network tab of your browser will reveal the correct redirection to the FULL URL in that's in the RD parameter https://subdomain2.subdomain.domain.org/api/auth/error, then when you've been redirected to https://subdomain2.subdomain.domain.org/api/auth/error the application itself or the proxy are redirecting you to /api/auth/error.

[james-d-elliott]

Any updates?

[distributev]

Yes, you were right /api/auth/error comes from next-auth which is used by the protected app and most likely next-auth session expired and, together witu authelia being expired, it shows the /?rd=https%3A%2F%2Fsubdomain2.subdomain.domain.org%2Fapi%2Fauth%2Ferror

I increased the next-auth session maxAge to see if it will make any difference.

[james-d-elliott]

Alright, awesome. I'll close this off. You're welcome to open another bug report, reopen this one with a reply, or open a discussion regarding next auth if you can't figure it out.