authentication on the endpoint

[alexjyong]

Feature Request

Is there a way to have authentication on the endpoint for this? I feel like anyone with access to the server name and IP address can just go and use it for automated messages with their signal account. Or is that not how it works?

[bbernhard]

I've thought about adding authentication and SSL support a number of times, but always decided against it. The main reason for that is, that this would add quite a lot of additional dependencies that I need to maintain and keep up to date. That being said, I totally understand that one wants to protect the API against misuse. But authentication (and SSL support) can quite easily be added by using a reverse proxy. Unfortunately there is no documentation for this available right now, but you should find plenty tutorials for nginx, traefik, caddy, etc.

[alexjyong]

What about an option for basic auth? That might be Better Than Nothing™. I could use some more green squares on my Github graph, 😅 so I could try whipping up a PR for this. I could try adding basic auth, and a documentation update on how to do it with a recommendation to put this through a reverse proxy for more advanced needs.

[bbernhard]

I totally get you - it is also tempting for me to implement something like that. It's easy & fun to implement. But I am a bit worried that this will result in a bunch of future feature requests like "It would be great to have support for multiple users", "Why only basic auth?", "I want that user xy only can access a small subset of endpoints", "Without SSL basic auth is worthless" etc. In the end we have built another reverse proxy - with less capabilities and more bugs. :sweat_smile:.

And I am also not really sure how many people will really be happy with "just" basic auth. Don't get me wrong, it is still better than nothing. But I guess those people that really care about securing the access to the API (because they expose it publicly), they probably want to have SSL too. And then you are really better off with a reverse proxy.

I think in the end the time is probably spent better writing some good documentation on how to set up something like this yourself (which is definitely something I would love to have some documention for)

If there is really a lot of demand from the community, I am definitely open to reconsider that decision. But in the past years there were only two(?) issues with such a request. So I think most of the people are fine with a reverse proxy :)

[alexjyong]

@bbernhard understandable. Basically the idea came from when I was setting up Uptime Kuma (and this is how I found out about your project!) when I saw I could use Signal for notifications.

This seemed cool, but the lack of auth jumped out at me. But since you can also do generic webhook notifications as well, I probably could put this behind the auth of my choosing, then make the call that way.

I can see what reverse proxy documentation would look like.

[shivamkb17]

hi, The authentication of the request is really a great ideas. Do you planning to implement it.

[alexjyong]

It doesn't seem to be in the interest of the repo owner to do so but if that changes and if I have time I might be interested in setting up something basic at least.

On Tue, Jul 2, 2024, 8:28 AM Shivam Kumar @.***> wrote:

hi, The authentication of the request is really a great ideas. Do you planning to implement it.

— Reply to this email directly, view it on GitHub https://github.com/bbernhard/signal-cli-rest-api/issues/519#issuecomment-2203035427, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJWCVDD5ZDTGZ4UKOGPN5DZKKMGTAVCNFSM6AAAAABGLVMNHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBTGAZTKNBSG4 . You are receiving this because you authored the thread.Message ID: @.***>