starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

allow bearer auth for signal notifications #4058

New issue

Open

opened 2026-02-28 03:49:43 -05:00 by deekerman · 14 comments

deekerman commented

2026-02-28 03:49:43 -05:00

Owner

Originally created by @babeuloula on GitHub (Mar 30, 2025).

🏷️ Feature Request Type

Settings

🔖 Feature description

Hello,

I'm using Signal and I've blocked the endpoint though a basic auth. I can't use the Signal notification because I can't setting up an authentification system.

✔️ Solution

I think it would be great if we can setting up an auth system for notification provider.

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @babeuloula on GitHub (Mar 30, 2025). ### 📑 I have found these related issues/pull requests . ### 🏷️ Feature Request Type Settings ### 🔖 Feature description Hello, I'm using Signal and I've blocked the endpoint though a basic auth. I can't use the Signal notification because I can't setting up an authentification system. ### ✔️ Solution I think it would be great if we can setting up an auth system for notification provider. ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman added the

feature-request

A:notifications

type:enhance-existing

labels

2026-02-28 03:49:43 -05:00

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@101br03k commented on GitHub (Mar 30, 2025):

uptime-kuma uses apprise as an notification system. Please check there documentation for how to use Signal using an API: https://github.com/caronc/apprise/wiki/Notify_signal

@101br03k commented on GitHub (Mar 30, 2025): uptime-kuma uses apprise as an notification system. Please check there documentation for how to use Signal using an API: https://github.com/caronc/apprise/wiki/Notify_signal

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@babeuloula commented on GitHub (Mar 30, 2025):

uptime-kuma uses apprise as an notification system. Please check there documentation for how to use Signal using an API: Wiki: Notify_signal (caronc/apprise)

I've already tried this.

But signal:// is not a valid protocol:

And if I use https://, I can't setting up my password because it contain special chars. I've also tried with a base64 encoded password. I've always an error 401.

@babeuloula commented on GitHub (Mar 30, 2025): > uptime-kuma uses apprise as an notification system. Please check there documentation for how to use Signal using an API: [Wiki: Notify_signal (caronc/apprise)](https://github.com/caronc/apprise/wiki/Notify_signal) I've already tried this. But `signal://` is not a valid protocol: ![Image](https://github.com/user-attachments/assets/a911d661-31d5-47f8-9f18-c6e32598515d) And if I use `https://`, I can't setting up my password because it contain special chars. I've also tried with a base64 encoded password. I've always an error 401.

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@101br03k commented on GitHub (Mar 30, 2025):

Ah yes, because it already asks you to select the type in the notifications section it is not needed to specify any fearther.
Do you have a signal client with REST API?
For example https://github.com/bbernhard/signal-cli-rest-api

@101br03k commented on GitHub (Mar 30, 2025): Ah yes, because it already asks you to select the type in the notifications section it is not needed to specify any fearther. Do you have a signal client with REST API? For example https://github.com/bbernhard/signal-cli-rest-api

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@babeuloula commented on GitHub (Mar 30, 2025):

Yes of course I have a signal client with REST API. But I don't understand how to settting up my basic auth.

@babeuloula commented on GitHub (Mar 30, 2025): Yes of course I have a signal client with REST API. But I don't understand how to settting up my basic auth. ![Image](https://github.com/user-attachments/assets/1e485372-d2d9-43dc-bcf1-6b7a68c77425)

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@101br03k commented on GitHub (Mar 30, 2025):

You don't need basic auth, at http://IP:PORT/v1/qrcodelink?device_name=signal-api you can connect your phone to the container, then using a configuration comparable to this it works for me.

@101br03k commented on GitHub (Mar 30, 2025): You don't need basic auth, at http://IP:PORT/v1/qrcodelink?device_name=signal-api you can connect your phone to the container, then using a configuration comparable to this it works for me. ![Image](https://github.com/user-attachments/assets/a5d6132e-dd5c-48fa-aaf0-dfa22c800b03)

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@babeuloula commented on GitHub (Mar 30, 2025):

No I need a basic auth because my endpoint is protected by a basic auth. I don't want to expose the signal API to anyone.

@babeuloula commented on GitHub (Mar 30, 2025): No I need a basic auth because my endpoint is protected by a basic auth. I don't want to expose the signal API to anyone.

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@101br03k commented on GitHub (Mar 30, 2025):

What do you mean with "my endpoint"?
https://github.com/bbernhard/signal-cli-rest-api or another rest api?
Quickly looking trough the docs of the mentiond repository I do not see any option for this. Are you using a reverse proxy or something similar?

@101br03k commented on GitHub (Mar 30, 2025): What do you mean with "my endpoint"? https://github.com/bbernhard/signal-cli-rest-api or another rest api? Quickly looking trough the docs of the mentiond repository I do not see any option for this. Are you using a reverse proxy or something similar?

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@babeuloula commented on GitHub (Mar 30, 2025):

Yes I use a nginx reverse proxy to serve the REST API

@babeuloula commented on GitHub (Mar 30, 2025): Yes I use a nginx reverse proxy to serve the REST API

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@damitti444 commented on GitHub (Apr 1, 2025):

I don't know if this is supported by uptime-kuma but have you tried passing credentials in the URL like this?
https://user:pass123@example.com/.....
source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication#access_using_credentials_in_the_url
also consider the security implications if you use this, i.e. password visible in logs

@damitti444 commented on GitHub (Apr 1, 2025): I don't know if this is supported by uptime-kuma but have you tried passing credentials in the URL like this? https://user:pass123@example.com/..... source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication#access_using_credentials_in_the_url also consider the security implications if you use this, i.e. password visible in logs

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@babeuloula commented on GitHub (Apr 2, 2025):

I don't know if this is supported by uptime-kuma but have you tried passing credentials in the URL like this? user:pass123@example.com..... source: developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication#access_using_credentials_in_the_url also consider the security implications if you use this, i.e. password visible in logs

Hello, Yes I've tried this and also with a base64 encoded password but I've got an error 401.

@babeuloula commented on GitHub (Apr 2, 2025): > I don't know if this is supported by uptime-kuma but have you tried passing credentials in the URL like this? [user:pass123@example.com](https://user:pass123@example.com/)..... source: [developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication#access_using_credentials_in_the_url](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication#access_using_credentials_in_the_url) also consider the security implications if you use this, i.e. password visible in logs Hello, Yes I've tried this and also with a base64 encoded password but I've got an error 401.

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@FoxOps commented on GitHub (May 14, 2025):

Yes I use a nginx reverse proxy to serve the REST API

Hello,

I don't think this is a Kuma problem, perse. More like a configuration on the reverse proxy side but a better management of auth on kuma side is always welcomed.

If you use nginx as a reverse proxy, there is another way to protect your signal API from unwanted traffic.

You can use "deny" and "allow" in nginx like this:

    location / {
        error_page 403 /error/error403.html; # If you want a custom error page
        error_page 404 /error/error.404html; # If you want a custom error page
        allow 192.168.0.1; # Your UptimeKuma IP v4 
	allow 3f8a:7c1d:4e2b:9a05:11f3:fd17:7e84:c484; # Your UptimeKuma IP v6
        deny all;
       # Whatever your reverse proxy settings are
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:123456/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
    location /error {
        alias /var/www/html/error/;
        internal;
    }

This should help you.

@FoxOps commented on GitHub (May 14, 2025): > Yes I use a nginx reverse proxy to serve the REST API Hello, I don't think this is a Kuma problem, perse. More like a configuration on the reverse proxy side but a better management of auth on kuma side is always welcomed. If you use nginx as a reverse proxy, there is another way to protect your signal API from unwanted traffic. You can use "deny" and "allow" in nginx like this: ``` location / { error_page 403 /error/error403.html; # If you want a custom error page error_page 404 /error/error.404html; # If you want a custom error page allow 192.168.0.1; # Your UptimeKuma IP v4 allow 3f8a:7c1d:4e2b:9a05:11f3:fd17:7e84:c484; # Your UptimeKuma IP v6 deny all; # Whatever your reverse proxy settings are proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_pass http://127.0.0.1:123456/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /error { alias /var/www/html/error/; internal; } ``` This should help you.

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@babeuloula commented on GitHub (May 14, 2025):

@FoxOps Thanks for the suggestion but unfortunately I can't set up IP filtering, I have several services accessing this service and I have dynamic IPs in particular.

@babeuloula commented on GitHub (May 14, 2025): @FoxOps Thanks for the suggestion but unfortunately I can't set up IP filtering, I have several services accessing this service and I have dynamic IPs in particular.

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@shred commented on GitHub (Oct 20, 2025):

I found this issue because I'm having the same problem.

Situation: I run a bbernhard/signal-cli-rest-api behind a reverse proxy that is publicy accessible. To avoid use of the Signal endpoint by unauthorized users, the reverse proxy checks for the presence of certain bearer tokens.

It would be great if uptime-kuma offers an "API token" field that is sent as "Authorization: Bearer" token. Alternatively passing an SSL client certificate, or credentials for a HTTP basic auth.

@shred commented on GitHub (Oct 20, 2025): I found this issue because I'm having the same problem. Situation: I run a [bbernhard/signal-cli-rest-api](https://github.com/bbernhard/signal-cli-rest-api) behind a reverse proxy that is publicy accessible. To avoid use of the Signal endpoint by unauthorized users, the reverse proxy checks for the presence of certain bearer tokens. It would be great if uptime-kuma offers an "API token" field that is sent as "Authorization: Bearer" token. Alternatively passing an SSL client certificate, or credentials for a HTTP basic auth.

deekerman commented

2026-02-28 03:49:49 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Oct 20, 2025):

If you’d like to see this added, feel free to open a pull request!
I’d be happy to consider it if it includes the required screenshots and makes the feature opt-in (for example, with a checkbox and a short help text explaining when or why to enable it).

No need for more “+1” comments — contributions are much more helpful 🙂

@CommanderStorm commented on GitHub (Oct 20, 2025): If you’d like to see this added, feel free to open a pull request! I’d be happy to consider it if it includes the required screenshots and makes the feature opt-in (for example, with a checkbox and a short help text explaining when or why to enable it). No need for more “+1” comments — contributions are much more helpful 🙂