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 1369]

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.