starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 08:26:00 +02:00

[GH-ISSUE #1601] [Web UI] Cannot log in when serving ntfy behind an authenticating reverse proxy #1124

New issue

Closed

opened 2026-05-07 00:30:26 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

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

Owner

Originally created by @riaeh on GitHub (Feb 9, 2026).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1601

🐞 Describe the bug

Hi,

I have been setting up a self-hosted instance of ntfy behind an authenticating reverse-proxy and I'm currently facing an issue where the login page redirects to itself (/login) after using valid credentials.
For reference, this is the same problem as described in #1473.

💻 Components impacted

ntfy web UI

💡 Screenshots and/or logs

See below

🔮 Additional context

I investigated a bit and the problem seems to come from the fact that during the authentication process, the GET request made to the /v1/account endpoint gets rejected by the authenticating reverse proxy with an HTTP 401.

Browser's console relevant logs:

[AccountApi] Checking auth for https://<REDACTED>/v1/account/token
[Login] User auth for user admin successful, token is <REDACTED>
...
[AccountApi] Syncing account
[AccountApi] Fetching user account https://<REDACTED>/v1/account
...
[ConnectionManager] Refreshing connections
[ConnectionManager] Starting new connection <REDACTED> (subscription https://<REDACTED>/<REDACTED> with user admin)
[Connection, <REDACTED>, <REDACTED>] Opening connection to wss://<REDACTED>/<REDACTED>/ws?auth=<REDACTED>
[ConnectionManager] Starting new connection <REDACTED> (subscription https://<REDACTED>/test with user admin)
[Connection, <REDACTED>/test, <REDACTED>] Opening connection to wss://<REDACTED>/test/ws?since=<REDACTED>&auth=<REDACTED>
[Error] HTTP 401  Response { type: "basic", url: "https://<REDACTED>/v1/account", redirected: false, status: 401, ok: false, statusText: "Unauthorized", headers: Headers(6), body: ReadableStream, bodyUsed: false }
[AccountApi] Error fetching account Error: Unauthorized
Navigated to https://<REDACTED>/login
...

This is due to the fact that this specific request's Authorization header contains a bearer token generated by ntfy rather than the basic auth credentials expected by the reverse proxy. From my very basic understand of the authentication process used by ntfy, when logging in through the web UI, ntfy generates a bearer token for the relevant account and then uses that token for subsequent requests, thus causing these requests to get rejected by an authenticating reverse proxy that uses basic auth.

The error then causes a redirect to the login page once again.

I'm not familiar with ntfy's source code nor JS apps in general but I'm guessing that this specific behavior is implemented in this function:

github.com/binwiederhier/ntfy@7860f2142c/web/src/app/AccountApi.js (L79-L91)

Editing that request's Authorization header to use the basic auth credentials instead of the bearer token allows the request to go through the reverse proxy:

I'm not sure that this is particularly a bug per se but I was wondering if there was any way of changing that behavior in a way that such requests could be made using the basic auth credentials in the Authorization header.

For context, I am using the same credentials as the ntfy user on the reverse proxy. This may look convoluted because ntfy already handles authentication but in the case where one is exposing an ntfy instance on the internet, using an authenticating proxy in such a way prevents anonymous users from even seeing the ntfy login page (facing the proxy's one instead and thus not revealing the presence of an ntfy instance).

Feel free to close this if this is intended behavior :)

Have a nice day,

Originally created by @riaeh on GitHub (Feb 9, 2026). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1601 :lady_beetle: **Describe the bug**  Hi, I have been setting up a self-hosted instance of ntfy behind an authenticating reverse-proxy and I'm currently facing an issue where the login page redirects to itself (/login) after using valid credentials. For reference, this is the same problem as described in #1473. :computer: **Components impacted**  ntfy web UI :bulb: **Screenshots and/or logs**  See below :crystal_ball: **Additional context**  I investigated a bit and the problem seems to come from the fact that during the authentication process, the `GET` request made to the `/v1/account` endpoint gets rejected by the authenticating reverse proxy with an `HTTP 401`. <img width="1920" height="344" alt="Image" src="https://github.com/user-attachments/assets/a320e97e-ea13-4307-be58-2791bd6de58b" /> Browser's console relevant logs: ``` [AccountApi] Checking auth for https://<REDACTED>/v1/account/token [Login] User auth for user admin successful, token is <REDACTED> ... [AccountApi] Syncing account [AccountApi] Fetching user account https://<REDACTED>/v1/account ... [ConnectionManager] Refreshing connections [ConnectionManager] Starting new connection <REDACTED> (subscription https://<REDACTED>/<REDACTED> with user admin) [Connection, <REDACTED>, <REDACTED>] Opening connection to wss://<REDACTED>/<REDACTED>/ws?auth=<REDACTED> [ConnectionManager] Starting new connection <REDACTED> (subscription https://<REDACTED>/test with user admin) [Connection, <REDACTED>/test, <REDACTED>] Opening connection to wss://<REDACTED>/test/ws?since=<REDACTED>&auth=<REDACTED> [Error] HTTP 401 Response { type: "basic", url: "https://<REDACTED>/v1/account", redirected: false, status: 401, ok: false, statusText: "Unauthorized", headers: Headers(6), body: ReadableStream, bodyUsed: false } [AccountApi] Error fetching account Error: Unauthorized Navigated to https://<REDACTED>/login ... ``` This is due to the fact that this specific request's `Authorization` header contains a bearer token generated by ntfy rather than the basic auth credentials expected by the reverse proxy. From my very basic understand of the authentication process used by ntfy, when logging in through the web UI, ntfy generates a bearer token for the relevant account and then uses that token for subsequent requests, thus causing these requests to get rejected by an authenticating reverse proxy that uses basic auth. The error then causes a redirect to the login page once again. I'm not familiar with ntfy's source code nor JS apps in general but I'm guessing that this specific behavior is implemented in this function: https://github.com/binwiederhier/ntfy/blob/7860f2142c2f4c9ad13ba641f225fab30bbab049/web/src/app/AccountApi.js#L79-L91 Editing that request's `Authorization` header to use the basic auth credentials instead of the bearer token allows the request to go through the reverse proxy: <img width="1920" height="352" alt="Image" src="https://github.com/user-attachments/assets/c7350531-5d6d-4308-84e8-04836bb60572" /> I'm not sure that this is particularly a bug per se but I was wondering if there was any way of changing that behavior in a way that such requests could be made using the basic auth credentials in the `Authorization` header. For context, I am using the same credentials as the ntfy user on the reverse proxy. This may look convoluted because ntfy already handles authentication but in the case where one is exposing an ntfy instance on the internet, using an authenticating proxy in such a way prevents anonymous users from even seeing the ntfy login page (facing the proxy's one instead and thus not revealing the presence of an ntfy instance). Feel free to close this if this is intended behavior :) Have a nice day,

BreizhHardware

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

closed this issue
added the
web-app

🪲 bug

server
labels

BreizhHardware commented

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

Author

Owner

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

Thank you for the VERY detailed ticket description!! Incredible work.

However, this is not a bug. It's simply not a feature that is supported right now, so technically it's a feature request. There is a pinned issue here (https://github.com/binwiederhier/ntfy/issues/601) which is effectively a dup of this, and a half-done implementation in that issue as well. So this is a dup of #601.

There is way more to it than just the auth header though. Scroll to the bottom of the other issue to read more.

@binwiederhier commented on GitHub (Feb 9, 2026): Thank you for the VERY detailed ticket description!! Incredible work. However, this is not a bug. It's simply not a feature that is supported right now, so technically it's a feature request. There is a pinned issue here (https://github.com/binwiederhier/ntfy/issues/601) which is effectively a dup of this, and a half-done implementation in that issue as well. So this is a dup of #601. There is way more to it than just the auth header though. Scroll to the bottom of the other issue to read more.

BreizhHardware commented

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

Author

Owner

@riaeh commented on GitHub (Feb 9, 2026):

Hi, thanks for the quick reply!

Thank you for the clarification and the linked issue which I was unaware of.
I'll close this and follow the progress on the linked issue.

@riaeh commented on GitHub (Feb 9, 2026): Hi, thanks for the quick reply! Thank you for the clarification and the linked issue which I was unaware of. I'll close this and follow the progress on the linked issue.

BreizhHardware commented

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

Author

Owner

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

Feel free to test the branch I made as well and tell me what works and what doesn't. I still don't know how to proceed with Android in that regard.

@binwiederhier commented on GitHub (Feb 9, 2026): Feel free to test the branch I made as well and tell me what works and what doesn't. I still don't know how to proceed with Android in that regard.