[GH-ISSUE #373] [BUG] Cannot log in when authelia blocks the request #142

New issue

Open

opened 2026-02-27 08:15:30 +03:00 by kerem · 4 comments

kerem commented

2026-02-27 08:15:30 +03:00

Owner

Originally created by @ptoulouse on GitHub (Nov 18, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/373

Strange issue here. I configured both lldap and authelia according to the documentation in this repo.

When I try to reach lldap.example.com, I first hit authelia. I then authenticate, then get redirected to lldap. If I go back to authelia login page (auth.example.com) and logout on that page, I can still access lldap.example.com afterward. However username and password won't work.

I have to clear cookies to get redirected to authelia again when trying to reach lldap.example.com. AS far as I know, LLDAP is the only app that I have deployed that shows this behavior.

Originally created by @ptoulouse on GitHub (Nov 18, 2022). Original GitHub issue: https://github.com/lldap/lldap/issues/373 Strange issue here. I configured both lldap and authelia according to the documentation in this repo. When I try to reach lldap.example.com, I first hit authelia. I then authenticate, then get redirected to lldap. If I go back to authelia login page (auth.example.com) and logout on that page, I can still access lldap.example.com afterward. However username and password won't work. I have to clear cookies to get redirected to authelia again when trying to reach lldap.example.com. AS far as I know, LLDAP is the only app that I have deployed that shows this behavior.

kerem added the

enhancement

frontend

labels

2026-02-27 08:15:30 +03:00

kerem commented

2026-02-27 08:15:30 +03:00

Author

Owner

@nitnelave commented on GitHub (Nov 18, 2022):

It's probably due to the cache: loading the LLDAP page only loads static assets that are cached by your browser (the code of the SPA), so Authelia doesn't get a chance to trigger.
But when you try to log in, it has to check with the server if the password is correct. At that point, the request is blocked by Authelia since you're not logged in, so it shows up as "password is wrong" even though it's actually a redirect to the Authelia login page.

I guess the cleanest way to handle that would be to add support for the Authelia cookies (so if you're logged in to Authelia you're logged in to LLDAP), and check the LLDAP log in response to see if Authelia highjacked it.

@nitnelave commented on GitHub (Nov 18, 2022): It's probably due to the cache: loading the LLDAP page only loads static assets that are cached by your browser (the code of the SPA), so Authelia doesn't get a chance to trigger. But when you try to log in, it has to check with the server if the password is correct. At that point, the request is blocked by Authelia since you're not logged in, so it shows up as "password is wrong" even though it's actually a redirect to the Authelia login page. I guess the cleanest way to handle that would be to add support for the Authelia cookies (so if you're logged in to Authelia you're logged in to LLDAP), and check the LLDAP log in response to see if Authelia highjacked it.

kerem commented

2026-02-27 08:15:30 +03:00

Author

Owner

@pixelrazor commented on GitHub (Dec 16, 2022):

It's probably due to the cache: loading the LLDAP page only loads static assets that are cached by your browser (the code of the SPA), so Authelia doesn't get a chance to trigger.
But when you try to log in, it has to check with the server if the password is correct. At that point, the request is blocked by Authelia since you're not logged in, so it shows up as "password is wrong" even though it's actually a redirect to the Authelia login page.

I guess the cleanest way to handle that would be to add support for the Authelia cookies (so if you're logged in to Authelia you're logged in to LLDAP), and check the LLDAP log in response to see if Authelia highjacked it.

Would it be preferred to use trusted header auth over the authelia cookie?

@pixelrazor commented on GitHub (Dec 16, 2022): > It's probably due to the cache: loading the LLDAP page only loads static assets that are cached by your browser (the code of the SPA), so Authelia doesn't get a chance to trigger. > But when you try to log in, it has to check with the server if the password is correct. At that point, the request is blocked by Authelia since you're not logged in, so it shows up as "password is wrong" even though it's actually a redirect to the Authelia login page. > > I guess the cleanest way to handle that would be to add support for the Authelia cookies (so if you're logged in to Authelia you're logged in to LLDAP), and check the LLDAP log in response to see if Authelia highjacked it. Would it be preferred to use trusted header auth over the authelia cookie?

kerem commented

2026-02-27 08:15:30 +03:00

Author

Owner

@nitnelave commented on GitHub (Dec 16, 2022):

Yes, trusted header is probably better.

On Fri, 16 Dec 2022, 22:18 Austin Alvarado, @.***>
wrote:

It's probably due to the cache: loading the LLDAP page only loads static
assets that are cached by your browser (the code of the SPA), so Authelia
doesn't get a chance to trigger.
But when you try to log in, it has to check with the server if the
password is correct. At that point, the request is blocked by Authelia
since you're not logged in, so it shows up as "password is wrong" even
though it's actually a redirect to the Authelia login page.

I guess the cleanest way to handle that would be to add support for the
Authelia cookies (so if you're logged in to Authelia you're logged in to
LLDAP), and check the LLDAP log in response to see if Authelia highjacked
it.

Would it be preferred to use trusted header auth over the authelia cookie?

—
Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/373#issuecomment-1355621760,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWK42REH7DGZJWORU4LWNTMCJANCNFSM6AAAAAASEDTRDI
.
You are receiving this because you commented.Message ID:
@.***>

@nitnelave commented on GitHub (Dec 16, 2022): Yes, trusted header is probably better. On Fri, 16 Dec 2022, 22:18 Austin Alvarado, ***@***.***> wrote: > It's probably due to the cache: loading the LLDAP page only loads static > assets that are cached by your browser (the code of the SPA), so Authelia > doesn't get a chance to trigger. > But when you try to log in, it has to check with the server if the > password is correct. At that point, the request is blocked by Authelia > since you're not logged in, so it shows up as "password is wrong" even > though it's actually a redirect to the Authelia login page. > > I guess the cleanest way to handle that would be to add support for the > Authelia cookies (so if you're logged in to Authelia you're logged in to > LLDAP), and check the LLDAP log in response to see if Authelia highjacked > it. > > Would it be preferred to use trusted header auth over the authelia cookie? > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/373#issuecomment-1355621760>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWK42REH7DGZJWORU4LWNTMCJANCNFSM6AAAAAASEDTRDI> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

kerem commented

2026-02-27 08:15:30 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 21, 2023):

Related: #352

@nitnelave commented on GitHub (Mar 21, 2023): Related: #352

kerem referenced this issue

2026-02-27 08:18:01 +03:00

[PR #145] [MERGED] app: add bottom padding to avoid overlap with the footer #569