Deny WebUI access to anonymous users

[ryester19]

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]

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

[ryester19]

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]

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]

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

[ryester19]

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]

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]

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

[binwiederhier]

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]

web-enabled = true|false

I'm working on this.

[binwiederhier]

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

web-login = none|admin|user

[ntccloud]

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

[lazee486]

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 :)

[Mat-DB]

It's an older issue but I am thinking to use authelia to put in front of the UI, just the UI. Just to give an other option here to make it "more secure".

To be clear I have authelia running for other things already and I know that it doesn't add anything in security to NTFY.
Just a pease of mind thing I guess.

Thanks to the maintainers btw!! Great project!
I am comparing Gotify and NTFY and I think NTFY is winning.

Edit 1: Authelia in front of ntfy is a nightmare. So I am going to leave it like this! Sorry for the possible spam.