mirror of
https://github.com/asalimonov/authelia-admin.git
synced 2026-04-25 14:45:56 +03:00
[GH-ISSUE #37] Question regarding Traefik #8
Labels
No labels
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/authelia-admin#8
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?
Originally created by @arcoast on GitHub (Dec 7, 2025).
Original GitHub issue: https://github.com/asalimonov/authelia-admin/issues/37
I've been using authelia for years and have it working with Traefik, but struggling with the routing with authelia-admin.
My Authelia config is as follows, running on a dedicated subdomain
My authelia-admin configuration is done using environmental variables
If I go to
authelia.domain.comI can successfully use Authelia, however trying to browse tohttps://authelia.domain.com/auth-adminresults in a 500 error code and an internal server error.Looking in the browser logs
Docker logs for authelia-admin are fine
I can browse to http://SERVER_IP:9093/auth-admin and see the following page
The Authelia link points to
http://SERVER_IP:9093and the Authelia-Admin link points tohttp://SERVER_IP:9093/auth-adminI understand this may be out of scope for support as it's almost certainly a Traefik issue, but I did notice that I think you're using Traefik yourself based on the compose file here
I did wonder if it might be a CORS issue, however I'm using the same Traefik routing with PathPrefix in another stack (running
/.well-known/matrix/) on my root domain to facilitate OIDC in my Synapse server.Would be very grateful for any advice, help or insights you might be able to offer.
One other thought I had, is that as you can see I've split my Authelia config file into multiple files to help with readability/editing, and I wondered if that might impact things.
@asalimonov commented on GitHub (Dec 7, 2025):
@arcoast ,
Traefik rules(labels) look OK for the first sight.
My hypothesizes:
const authResponse = await fetch(`https://${authelia.domain}/api/state`, { ..., so I would check DNS resolutions from this docker network, certificate verification in case of self-signed certificate forauthelia.domain.comand network routes in case of enabled VPN on this host with this docker-compose.notstatement in route routes, anthelia-adminHost(`authelia.domain.com`) && PathPrefix(`/auth-admin`)should have higher priority in comparison withHost(`authelia.domain.com`)- "traefik.http.services.authelia.loadBalancer.passHostHeader=true"and- "traefik.http.services.authelia-admin.loadBalancer.passHostHeader=true"labels@arcoast commented on GitHub (Dec 7, 2025):
Thanks for the reply.
Regarding point 1:
I'm using a FQDN with certs obtained via certbot using Traefik and can confirm DNS resolution from authelia-admin (I run my own authoritative DNS server, with split DNS so the IP address is that of my Traefik host)
I can succesfully hit https://authelia.DOMAIN.COM from the authelia-admin container
Tried adding the suggestions you made so my Authelia labels are now:
and my Authelia-Admin labels are now:
But nothing seems to change the outcome, at a bit of a loss to know what to try from this point.
@asalimonov commented on GitHub (Dec 8, 2025):
@arcoast , try this image with env var for docker container
-e AAD_LOGLEVEL=DEBUG \.ghcr.io/asalimonov/authelia-admin:2025-12-08orghcr.io/asalimonov/authelia-admin:sha-9f8b445. It is0.1.0version with merged https://github.com/asalimonov/authelia-admin/pull/46. Hope it will help to find a root cause.You should see something similar to this in case of success authentication:
@arcoast commented on GitHub (Dec 8, 2025):
So it seems it can't find the authentication cookie.
Here's the relevant part of my authelia config
And here's my authelia-admin config
Inspecting the browser though the cookie is indeed present
@asalimonov commented on GitHub (Dec 8, 2025):
Related code:
Looks like authelia-admin doesn't get requests from a balancer with "Cookie" header and key "authelia_session".
I guess some middleware filter out the header.
Or authelia-admin's has a bug with parsing of configs and env vars. The second assumption has low probability but there is no schema validation and unit tests.
@arcoast commented on GitHub (Dec 8, 2025):
So running with no middleware on either authelia & authelia-admin doesn't seem to change anything.
Although, looking at it again, I only get the cookie error when I browse
http://192.168.0.1:9093/auth-adminI get no errors reported in the log when I go to
https://authelia.DOMAIN.COM/auth-adminother than a 500 and "Internal Server Error"I'm really at a loss to no what to try now.
@asalimonov commented on GitHub (Dec 8, 2025):
Error is obvious due to luck of cookies
Is it error has same page style as for
http://SERVER_IP:9093/auth-adminon your screenshot?Tried to reproduce this issue. Tested cases of missing config file, bad yaml format, wrong authelia domain, wrong cookies name with wrong value of LOGLEVEL. And I couldn't reproduce 500 status code without logs. Very strange error. There is only absolutely standard code of adding paraglide (for i18n) in a pipeline of processing requests, and after that there is loading of configs.
@arcoast commented on GitHub (Dec 10, 2025):
So, I turned on debug logs in Traefik and found that whenever I tried to access
https://authelia.DOMAIN.COM/auth-adminI was gettingAfter a bit of searching I've found that changing my Traefik labels from
I have no real explanation for why the first configuration doesn't work, yet the second does, as to my eye, they are both identical on a practical level?
I can now access
https://authelia.DOMAIN.COM/auth-adminbut after logging in I'm now faced with the following errorMy authelia-admin configuration is as follows:
@asalimonov commented on GitHub (Dec 10, 2025):
@arcoast ,
I guess the second error occurs because the user is not a member of any of the following groups in LLDAP:
I changed behavior of the app when removed read-only access for any other user from LDAP. And forget to describe this part of configuration. Sorry about this, I will update README.md tomorrow.
@asalimonov commented on GitHub (Dec 22, 2025):
@arcoast, how are you doing? Did this solve the problem?