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

Deny WebUI access to anonymous users #238

Open
ryester19 opened this issue May 5, 2022 · 12 comments · Fixed by #249
Open

Deny WebUI access to anonymous users #238

ryester19 opened this issue May 5, 2022 · 12 comments · Fixed by #249
Labels
enhancement New feature or request web-app Web app things

Comments

@ryester19
Copy link

While the current ACL implementation allows you to deny subscribing and publishing for anonymous users, there's no way to prevent them from using the WebUI to connect to other servers. For a truly private server, anonymous users should be prevented from using the server at all

I have an idea on how this could be implemented:

  1. Introduce a new ACL permission that controls WebUI access
  2. Introduce a login screen at WebUI load
    • If WebUI access for anonymous users is allowed, the login screen is hidden
    • An added benefit is that you can use this authentication to forego asking users for credentials when adding local subscriptions later on
@binwiederhier
Copy link
Owner

Thank you very much for creating this ticket. It has been discussed many times on Discord, and it absolutely deserves a ticket.

I explained it many times before, but I'll explain it one last time here, so I can link to it later:

Dumb client: The web app is a dumb client only app. All the logic is implemented in JS in the browser. Having access to the web app gives you no access to the server. As you have correctly noted, the ACLs allow you to deny access to all topics, so having the web app exposed to the internet does not pose a security threat. Your server initially serves the HTML+ JS, but thats about it. In many ways, the web app is identical to the Android app. Having the app and having access to it does not mean having access to the server.

However, there is (as this ticket proves) a UX problem with this approach: people do not understand this paradigm. It is unusual for the web and not desired by selfhosters. People want login screens, even if that's just an illusion. Many people have requested this.

So, i give up. I'm going to implement a login screen. Just so I don't have to have this discussion again. It changes nothing from a security perspective, but it creates a more traditional UX.

And as we all know, UX is king 👑.

@binwiederhier binwiederhier added enhancement New feature or request web-app Web app things labels May 5, 2022
@ryester19
Copy link
Author

Oh man, I'm sorry. I wasn't aware people were bothering you about this before. I avoid Discord whenever I can, so I didn't know 😓

I can only speak for myself, but even having anonymous users use the web client is still being too open when you intend the server to be "private". Maybe it's a psychological thing, and we've all been accustomed to login screens acting as a roadblock to hold back the outside world. As tiny as it seems, a login screen would still provide a heightened level of access control on a network that is very public

@binwiederhier
Copy link
Owner

Hehe, no worries, nobody is bothering me. People are very nice, but (understandably so) very confused.

Maybe it's a psychological thing, and we've all been accustomed to login screens acting as a roadblock

I think it's more "you've been trained" that this way, so you now need it to feel safe. And that's okay. I'll add the screen :-D

heightened level of access control

This is incorrect.

It's gonna be literally showing a screen that was previously hidden (switching display: none to display: block), similar to how I implemented nopaste.net and phil.nopaste.net. Look at the source code of both in your browser. They are the same. Except that for phil.nopaste.net I only show the main UI after a valid password was entered.

If you are in the network already, you can

  • interact with the API directly
  • spin up your own ntfy web app (which then interacts with the API)

So you see, no additional security gain through the login. Only a psychological one.

@binwiederhier
Copy link
Owner

@ryester19 Btw, the Discord is bridged to Matrix too (https://matrix.to/#/#ntfy:matrix.org) if you like that more :-D

@ryester19
Copy link
Author

ryester19 commented May 6, 2022

This is incorrect

If the same resources are loaded whether there's a login prompt or not (as in your nopaste.net examples), then yes I would say it's pretty useless

However, if you're able to make it so that the static resources like 'main.2e44de94.js' are loaded only after successful authentication, then that would make this feature have some kind of purpose

@binwiederhier
Copy link
Owner

It's open source, and as I said you can just use the web app on ntfy.sh/app for instance to subscribe to any server. See what I mean?

@ryester19
Copy link
Author

Sounds to me there would be more practical purpose in just letting server admins disable the WebUI completely.

@binwiederhier
Copy link
Owner

I think the "illusion" is still worthwhile, even if it's just to avoid this discussion :-D

I was thinking:

web-enabled = true|false
web-login = none|admin|user

@Curid
Copy link
Contributor

Curid commented May 12, 2022

web-enabled = true|false

I'm working on this.

@binwiederhier
Copy link
Owner

Re-opening, since this is not entirely implemented. The hard part still has to be done:

web-login = none|admin|user

@ntccloud
Copy link

This problem is solved simply, use a webproxy like nginx for example, then you block / again, and only open the /topics.

@lazee486
Copy link

Im going to say incredibly wholesome debate and love your project :) Ive spun up my instance, and as a homelab user with docker and almost no experience, Ive left mine public, I don't mind if anyone uses it,I can see the effort that has gone into making it (not hacked together) so im not too worried about exploits, but I also know that decision was mainly because i didn't want to go through all the acl stuff just to get alerts from my devices....

a simple cosmetic privacy that helps with the people who know less like me will go a long way to making sure your software isn't abused because of my incompetence, and I thank you for working on it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request web-app Web app things
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants