[GH-ISSUE #1522] Login Not Working With Authelia #1073

New issue

Closed

opened 2026-05-07 00:30:03 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-07 00:30:03 +02:00

Owner

Originally created by @darkpixelftw on GitHub (Dec 24, 2025).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1522

🐞 Describe the bug

When trying to login to the ntfy (https://github.com/binwiederhier/ntfy - v2.15.0) webapp, the login fails no matter what method the user was created.

I finally tracked this down to authelia, it seems authelia is interpreting the credentials being sent as an Authelia user login attempt, see logs below

Steps to replicate:
Setup ntfy docker container, connected to authelia via a traefik middleware.
Setup ntfy user via file or commands (i tried both and both had this same error)
attempt to login through the ntfy webapp: https://ntfy.example.com/login
recieve error: Login failed: Invalid username or password
Remove authelia middleware from ntfy container
Login now works

💻 Components impacted

Webapp

💡 Screenshots and/or logs

From authelia logs
{"error":"failed to validate Authorization header with basic scheme: failed to validate the credentials of user 'REDACTED' parsed from the Authorization header: authentication failed. Cause: error occurred performing bind: LDAP Result Code 49 "Invalid Credentials": ","level":"error","method":"GET","msg":"Error occurred while attempting to authenticate a request","path":"/api/authz/forward-auth","remote_ip":"REDACTED","time":"REDACTED"}
🔮 Additional context

ntfy logs are empty - presumebly because the credentials are being intercepted by authelia, which doesn't recognise it and sends a signal saying it's not correct?

This appears to be an error with how the username/password are being sent to the web app. Not seen this happen with any other service I've set up with authelia so I'm assuming this is something to do with how ntfy sends the credentials to the server from my pc using the webapp rather than some non-standard behaviour with authelia.

Is there a possibility of sending the credentials in a different way to avoid this problem? or at least adding a warning to the documentation that this occurs.

Originally created by @darkpixelftw on GitHub (Dec 24, 2025). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1522 :lady_beetle: **Describe the bug**  When trying to login to the ntfy (https://github.com/binwiederhier/ntfy - v2.15.0) webapp, the login fails no matter what method the user was created. I finally tracked this down to authelia, it seems authelia is interpreting the credentials being sent as an Authelia user login attempt, see logs below Steps to replicate: Setup ntfy docker container, connected to authelia via a traefik middleware. Setup ntfy user via file or commands (i tried both and both had this same error) attempt to login through the ntfy webapp: https://ntfy.example.com/login recieve error: Login failed: Invalid username or password Remove authelia middleware from ntfy container Login now works :computer: **Components impacted**  Webapp :bulb: **Screenshots and/or logs**  From authelia logs {"error":"failed to validate Authorization header with basic scheme: failed to validate the credentials of user 'REDACTED' parsed from the Authorization header: authentication failed. Cause: error occurred performing bind: LDAP Result Code 49 \"Invalid Credentials\": ","level":"error","method":"GET","msg":"Error occurred while attempting to authenticate a request","path":"/api/authz/forward-auth","remote_ip":"REDACTED","time":"REDACTED"} :crystal_ball: **Additional context** ntfy logs are empty - presumebly because the credentials are being intercepted by authelia, which doesn't recognise it and sends a signal saying it's not correct?  This appears to be an error with how the username/password are being sent to the web app. Not seen this happen with any other service I've set up with authelia so I'm assuming this is something to do with how ntfy sends the credentials to the server from my pc using the webapp rather than some non-standard behaviour with authelia. Is there a possibility of sending the credentials in a different way to avoid this problem? or at least adding a warning to the documentation that this occurs.

BreizhHardware

2026-05-07 00:30:03 +02:00

closed this issue
added the
🪲 bug
label

BreizhHardware commented

2026-05-07 00:30:04 +02:00

Author

Owner

@wunter8 commented on GitHub (Dec 25, 2025):

Putting an auth service (like Authelia, Authentik, etc.) in front of ntfy is not supported right now

@wunter8 commented on GitHub (Dec 25, 2025): Putting an auth service (like Authelia, Authentik, etc.) in front of ntfy is not supported right now

BreizhHardware commented

2026-05-07 00:30:04 +02:00

Author

Owner

@llaumgui commented on GitHub (Jan 9, 2026):

c.) in front of ntfy is not supported right now

It's not the concern of this feature: https://github.com/binwiederhier/ntfy/pull/812/files#diff-fb0c696bc104f613e5b601c77c2eba916dd636d5948c9b5c8e85ea92ee5b07e6R55 ?

@llaumgui commented on GitHub (Jan 9, 2026): > c.) in front of ntfy is not supported right now It's not the concern of this feature: https://github.com/binwiederhier/ntfy/pull/812/files#diff-fb0c696bc104f613e5b601c77c2eba916dd636d5948c9b5c8e85ea92ee5b07e6R55 ?

BreizhHardware commented

2026-05-07 00:30:04 +02:00

Author

Owner

@wunter8 commented on GitHub (Jan 9, 2026):

@llaumgui that is the purpose of that feature. But that hasn't been added to the project yet, and that code hasn't been worked on since 2023. So, it is not supported right now.

There's a chance it'll be supported in the future. But at least with that specific pull request, there are some outstanding questions about the architecture/design of the feature.

@wunter8 commented on GitHub (Jan 9, 2026): @llaumgui that is the purpose of that feature. But that hasn't been added to the project yet, and that code hasn't been worked on since 2023. So, it is not supported _right now_. There's a chance it'll be supported in the future. But at least with that specific pull request, there are some outstanding questions about the architecture/design of the feature.

BreizhHardware commented

2026-05-07 00:30:04 +02:00

Author

Owner

@binwiederhier commented on GitHub (Feb 1, 2026):

This is a dup of #601 with a WIP PR in #1579

@binwiederhier commented on GitHub (Feb 1, 2026): This is a dup of #601 with a WIP PR in #1579