Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

authentication on the endpoint #519

Open
alexjyong opened this issue Apr 17, 2024 · 4 comments
Open

authentication on the endpoint #519

alexjyong opened this issue Apr 17, 2024 · 4 comments

Comments

@alexjyong
Copy link

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

bbernhard commented Apr 17, 2024

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. 😅.

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
Copy link
Author

@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.
image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants