Re-redirect after authentication #282
Labels
No labels
bug
chore
documentation
enhancement
help
in-progress
question
ready-for-release
released
translation
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
adam/gate#282
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe your idea for an enhancement:
If I use ProxyAuth to service-a.mydomain.com, I get redirected to voidauth.mydomain.com to authenticate.
So far so good.
But after the authentication I am 'just' logged in voidauth.mydomain.com. I need to go to service-a.mydomain.com manually.
I expect to re-redirect back to the initial service-a after the successful authentication.
Additional context:
Try to copy the behaviour from authelia?
Are you still seeing this issue after the other issues you were having were resolved?
No I still have this issue.
Only after the forward from the Portainer Login (deactivated the default login) I got send back to Portainer.
But somehow I get a new tab each time I need to login.
Hmm I am usind ARC browser, will try it with safari now.
If that does not work for you, I would like to try with debugging enabled to see if it becomes clear what is going wrong. You can enable debugging by setting the environment variable
ENABLE_DEBUG=true.Edit: actually I am planning a minor release today anyways, so switching to the beta
edgetag should not be neededI added the ENV, say the word with the release and I will look into it.
Released v1.9.1, might have some additional logging that could help. Do a login to a ProxyAuth Domain after clearing cookies (or just logging out of VoidAuth) and let me know what the debug logs say 🙂
So got some time, here is the sanitized log for a site which is behind a ProxyAuth - The redirect did not work:
I will add a log to the immich issue as well.
I am running new on :latest with debug enabled
I see what is probably causing the issue. On the first line of the logs, the 'url' should be the URL of the protected domain, not VoidAuth. That url is what the ProxyAuth domain is matched to, so as far as VoidAuth is concerned you were requesting access to
http://voidauth.mydomain.com/. That url is built from headers passed to VoidAuth from your reverse proxy, usually the X-Forwarded-* headers.Reverse proxies should set those headers automatically, you might have to set some flag on your reverse proxy to trust some upstream IP address if you have a nested reverse proxy, not sure.
Yes I got a nested system.
NPM -> traefik -> voidauth
You may got an idea what do check?
I don't really know to be honest, but you will need to set up traefik to 'trust' sensitive (x-forwarded-*) headers from your NPM instance. Maybe check out the
trustForwardHeaderfield for ForwardAuth, documentation hereI did setup trustForwardHeader, you got it in your documentation:
Two thoughts
EDIT: The second thought was my fault... I used the sanitized url
Well darn, I'm really not sure then. Maybe try setting the forwardAuth.address to the internal address instead of the external? So like
traefik.http.middlewares.voidauth.forwardAuth.address: 'http://voidauth:3000/api/authz/forward-auth'. If that doesn't work, maybe also make sure that Voidauth itself isn't protected by forwardAuth, I feel like that could cause issues.Hmm the forward to the local address works like before. Portainer Oauth still works, I thought this would result in an error.
ProxyAuth also perfectly fine. Do I need to restart the other container as well after changes on VoidAuth?
This is my NPM config to *.myDomain.com with SSL
Oh wait, I don't think nginx (and therefore NPM) sets those
X-Forwarded-*headers by default. I think you need to change the Custom Nginx Configuration section in NPM to something like:not sure that ^ is exactly right but I think that might be the problem
Hmm if I need to add that in NPM, do I need to add that also to the VoidAuth middleware for traefik?
Not sure I suppose it depends on your setup. Because you are using nested reverse proxies and also trying to use ProxyAuth Domains you just need to make sure that your first reverse proxy (NPM) is setting those headers, and that your second proxy (Traefik) trusts the first and forwards those headers on to the forwardauth middleware (VoidAuth). You will probably have to add that NPM Custom Configuration to any proxy hosts that are going to loop VoidAuth in for forward auth
Did you ever find out the issue ? I cannot make the redirection work. The redir always appear in the begin in in the log but it's always lost during the login process.
No, but I was stuck with oder topics the last few weeks.
What I found out, my authentication with Portainer works perfectly fine with a back route to Portainer.
I think this is a bug, because even when I force the redirection in the url it disappear just after the login. It seem the redir parameter is lost after login due to consent prompt op_scopes_missing. You can see proxyauth:false on /api/interaction despite proxyauth_url being present in /oidc/auth URL.
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/authz/auth-request"},"proxyauth":{"action":"redirect_to_login","reason":"session_not_found","url":"https://[DOMAIN]/","domain":"[DOMAIN]/*"},"response":{"statusCode":401,"location":"https://[AUTH_DOMAIN]/oidc/auth?client_id=auth_internal_client&response_type=none&scope=openid&redirect_uri=https%3A%2F%2F[AUTH_DOMAIN]%2Fapi%2Fcb%3Fredir%3Dhttps%253A%252F%252F[DOMAIN]%252F&proxyauth_url=https%3A%2F%2F[DOMAIN]%2F"}},"timestamp":1776093166490}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/user/me"},"response":{"statusCode":401}},"timestamp":1776093166744}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/public/config"},"response":{"statusCode":200}},"timestamp":1776093166823}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/interaction/exists"},"response":{"statusCode":404}},"timestamp":1776093166849}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/oidc/auth"},"response":{"statusCode":303,"location":"/api/interaction"}},"timestamp":1776093166869}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/interaction"},"interaction":{"prompt":"login","reasons":["login_prompt","no_session"],"client_id":"auth_internal_client","username":null,"proxyauth":false},"re
w Enable Watch d Detach
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/interaction/exists"},"response":{"statusCode":200}},"timestamp":1776093166947}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/interaction/exists"},"response":{"statusCode":200}},"timestamp":1776093172542}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"POST","path":"/api/interaction/login"},"login":{"userId":"a5fa6a86-6c16-4b0b-a2c3-0867a7e72697","amr":["pwd"]},"response":{"statusCode":200}},"timestamp":1776093172235}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/oidc/auth/0ODkYtWqu98hZhtdCBH-K1qrHR2jqAsfcrY3fQI6G3F"},"response":{"statusCode":303,"location":"/api/interaction"}},"timestamp":1776093172595}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/interaction"},"user":{"id":"a5fa6a86-6c16-4b0b-a2c3-0867a7e72697","username":"test","source":"session","amr":["pwd"]},"interaction":{"prompt":"consent","reasons":["op_scopes_missing"],"client_id":"auth_internal_client","username":"test","proxyauth":false},"response":{"statusCode":302,"location":"https://[AUTH_DOMAIN]/oidc/auth/rBJCyn8aCzrVBf-vAHOsoZJe8yVVbu3hxwA2nsPCfhh"}},"timestamp":1776093172637}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/oidc/auth/rBJCyn8aCzrVBf-vAHOsoZJe8yVVbu3hxwA2nsPCfhh"},"response":{"statusCode":303,"location":"https://[AUTH_DOMAIN]/api/cb?iss=https%3A%2F%2F[AUTH_DOMAIN]%2Foidc"}},"timestamp":1776093172686}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/cb"},"user":{"id":"a5fa6a86-6c16-4b0b-a2c3-0867a7e72697","username":"test","source":"session","amr":["pwd"]},"response":{"statusCode":302,"location":"https://[AUTH_DOMAIN]"}},"timestamp":1776093172731}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/user/me"},"user":{"id":"a5fa6a86-6c16-4b0b-a2c3-0867a7e72697","username":"test","source":"session","amr":["pwd"]},"response":{"statusCode":200}},"timestamp":1776093172915}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/public/config"},"user":{"id":"a5fa6a86-6c16-4b0b-a2c3-0867a7e72697","username":"test","source":"session","amr":["pwd"]},"response":{"statusCode":200}},"timestamp":1776093172949}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/user/me"},"user":{"id":"a5fa6a86-6c16-4b0b-a2c3-0867a7e72697","username":"test","source":"session","amr":["pwd"]},"response":{"statusCode":200}},"timestamp":1776093173057}
voidauth-1 | {"level":"debug","message":"API Response Sent","details":{"request":{"ip":"[IP_REDACTED]","method":"GET","path":"/api/user/passkeys"},"user":{"id":"a5fa6a86-6c16-4b0b-a2c3-0867a7e72697","username":"test","source":"session","amr":["pwd"]},"response":{"statusCode":200}},"timestamp":1776093173077}
I think I'm running into this issue as well. I'm running voidauth (version 1.12.3) on my Unraid server (version 7.2.6) for a couple of my exposed containers via Nginx. I am also noticing the behavior where I do not get redirected back to the intended domain after authenticating. Here is my relevant custom Nginx configuration:
include /data/nginx/snippets/auth-location.conf;
location / {
include /data/nginx/snippets/proxy.conf;
include /data/nginx/snippets/proxy-auth.conf;
proxy_pass $forward_scheme://$server:$port;
}
After authenticating, I can visit the intended domain with no issue. Any ideas on what I might be able to do to fix it? It's also entirely possible I have incorrectly configured something within the docker container, I can never rule out my own error.
Unfortunately I don't know what causes this issue, I have not been able to replicate it on my local setup or in my development environment. If you set the
ENABLE_DEBUGenvironment variable totrueyou should see output logs that may indicate what is going wrong.The plot thickens: I assumed if I updated the DEFAULT_REDIRECT variable to a basic landing page with links for other pages, I would effectively solve my issue in the short term. Even with a new URL set as the DEFAULT_REDIRECT, after authenticating I'm left in voidauth. Reviewing the log output shows roughly two potential causes:
I hope this helps!