Disable webaccess to emby server?

[dcook 303]

2 hours ago, yocker said:

I think you are all talking against each other.

All hes asking is for a way to not have to have the webpage running when using the apps anyway.

I soooooort of a agree, having a website running that you don't need or want is just a security risk no matter how well made.
Not having the site would at least hide it better from unwanted guests.

I don't think we need the ability to turn it off though.

Exactly, why do I need to keep something exposed that I don't use or need.

There should be a way of disabling it on a whole or at least restrict it per user.

[darkassassin07 670]

3 hours ago, yocker said:

I think you are all talking against each other.

All hes asking is for a way to not have to have the webpage running when using the apps anyway.

I soooooort of a agree, having a website running that you don't need or want is just a security risk no matter how well made.
Not having the site would at least hide it better from unwanted guests.

I don't think we need the ability to turn it off though.

What you both don't seem to understand is that access to your server is exactly the same, whether you're using a regular web browser or a bespoke installable emby application/client. They all access the server through the exact same means/endpoints: the servers API, which is secured with user authentication tokens. The only difference is whether the interface you're viewing was downloaded on the fly to present to you (a web page) or already stored on your device (an installed application, or even just a locally cached version of the webpage). An attacker doesn't even need to load the webpage from your server, they could just send raw requests/commands directly to the servers API.

Disabling the 'http web server' or 'webpage' or however you want to phrase it, IS to shutdown Emby server entirely. (or prevent EVERYTHING from accessing it at all, apps included). Emby server is primarily an http server that responds to http requests from every client application. This includes the actual video streams too.

 

Point is: your request has not and very likely will not be implemented because it does nothing useful. Preventing users from being able to load the webpage would not improve security in anyway (and honestly would likely lead to people locking themselves out of their servers unknowingly). It's completely superfluous. Like removing the knocker from your door; it doesn't stop people seeing your house/door and knocking anyway or even just trying to enter. That's why we have locks (authentication/access controls).

 

If you're that worried about which client a user will use; use the device access controls to limit them. Or just have a discussion with the people you share your server with and stop sharing with people that won't respect your rules... It's your server after all.

[yocker 1370]

28 minutes ago, darkassassin07 said:

What you both don't seem to understand is that access to your server is exactly the same, whether you're using a regular web browser or a bespoke installable emby application/client. They all access the server through the exact same means/endpoints: the servers API, which is secured with user authentication tokens. The only difference is whether the interface you're viewing was downloaded on the fly to present to you (a web page) or already stored on your device (an installed application, or even just a locally cached version of the webpage). An attacker doesn't even need to load the webpage from your server, they could just send raw requests/commands directly to the servers API.

Disabling the 'http web server' or 'webpage' or however you want to phrase it, IS to shutdown Emby server entirely. (or prevent EVERYTHING from accessing it at all, apps included). Emby server is primarily an http server that responds to http requests from every client application. This includes the actual video streams too.

 

Point is: your request has not and very likely will not be implemented because it does nothing useful. Preventing users from being able to load the webpage would not improve security in anyway (and honestly would likely lead to people locking themselves out of their servers unknowingly). It's completely superfluous. Like removing the knocker from your door; it doesn't stop people seeing your house/door and knocking anyway or even just trying to enter. That's why we have locks (authentication/access controls).

 

If you're that worried about which client a user will use; use the device access controls to limit them. Or just have a discussion with the people you share your server with and stop sharing with people that won't respect your rules... It's your server after all.

I do understand.  

Just trying to convey what dcook means a bit better. 

[Lessaj 479]

I understand what they are asking, I've supported many applications that use a separate admin port - but they were all basically deployable web servers or multi-service like a file transfer platform, so the application running on the "normal" port(s) was completely separate. Here it's all part of the same service, using the same shared resources, so you can't just block it off. The security is already being enforced with user authentication tokens. It would essentially be an enhancement request to request separating admin functions into its own module.

[crusher11 1133]

8 hours ago, dcook said:

If HTML access is not a thing and is not needed, why can we not disable the HTML interface? 

I didn't say it wasn't needed, I said it wasn't a thing. It doesn't exist as distinct from any other kind of access.

9 hours ago, dcook said:

None of my users have admin access

Then they cannot access the admin dashboard. What's your problem?

9 hours ago, dcook said:

why do I have to expose to the internet the HTML web interface (which includes the Admin Dashboard

It only includes the admin dashboard for users with admin access, and the apps also include the admin dashboard, so, again, what's your point?

 

You're asking for someone to design a front door lock that only allows people through your door if they're wearing flip-flops, because you want people to be able to come into your house but you don't want them entering your bedroom. It's incoherent.

[sh0rty 727]

14 hours ago, Lessaj said:

While true, this is not completely accurate. You can change the URI to /emby/web from /web in the browser and everything works normally.

I guess you could allow/block access to the /web path based on User Agent string, but that can still be spoofed so you're probably better off just not giving people admin access.

This is correct. If someone knows the paths, the block is easily overcomable.

[dcook 303]

7 hours ago, darkassassin07 said:

If you're that worried about which client a user will use; use the device access controls to limit them. Or just have a discussion with the people you share your server with and stop sharing with people that won't respect your rules... It's your server after all.

If there were an option to deny access to web interface, that would be fine, however that doesn't seem to be the case, I can only restrict devices after they have already connected

[crusher11 1133]

18 minutes ago, dcook said:

If there were an option to deny access to web interface, that would be fine

But you don't need to do that! It doesn't achieve anything!

[dcook 303]

50 minutes ago, crusher11 said:

But you don't need to do that! It doesn't achieve anything!

It would remove access to the HTML web interface, but its not manageable, as I have to do it AFTER each user has already connected once per browser device, and the user could simply use a different browser, it would be easier to have a setting to simply disable HTML web access per user or globally.