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

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

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

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

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

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.

[crusher11 1135]

38 minutes ago, dcook said:

It would remove access to the HTML web interface

But that doesn't make any difference to anything, as you've been told a dozen times already.

[speechles 2062]

The HTML rendering is built into their client. As far as Emby server knows, the web browser, it uses a user-agent and connects to the API endpoint. Same as every other app whether web based, or Roku based, or iOS based, or etc. They all use the API endpoints and http connections. They send the server a user-agent and an authorization. Combined that grants you access to your user and you log in.

If you wish to disable users from being able to change things you can disable this on their user. You cannot disable their client from rendering HTML because that isn't how this works. You can only disallow them access to the API or restrict their access to certain API calls by changing their user settings. That is how it is meant to work.

Edited Thursday at 03:16 PM by speechles

[yocker 1373]

Proxys are not my strong suit but isn't it possible to white/black list client types?

[Lessaj 482]

2 hours ago, yocker said:

Proxys are not my strong suit but isn't it possible to white/black list client types?

  

23 hours ago, Lessaj said:

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.

^

[yocker 1373]

1 hour ago, Lessaj said:

  

^

Sorry, missed/forgot that. (I'm sick with feber, so go easy on me ) 

While spoofing is easy (even i can do it) it would require guessing the clients allowed.

Edited Thursday at 09:44 PM by yocker

[Lessaj 482]

6 minutes ago, yocker said:

Sorry, missed/forgot that. (I'm sick with feber, so go easy on me ) 

While spoofing is easy (even i can do it) it would require guessing the clients allowed.

It would, yes, but if only blocking certain things vs allowing certain things then you could make it say anything and it would pass. Allowing seems like a pretty big effort to keep up with vs blocking certain things. At the end of the day no one is going to do it anyway, because again it's all secured with user access tokens.

[C.S. 95]

It doesn't do anything for security, but from a purely administrative point of view there's a perfectly fine case for wanting the option to ban browsers.

It goes like this:
Browsers (often) suck, and as an admin I'd rather avoid dealing with the issues they present. And in my experience they seem to have issues with emby at least once in a while.

Recently I tried to watch an old video on my server with a modern up-to-date browser, and I got no sound. Then I tried it with the iphone app - worked great. Tried androidtv - works fine. Tried several other videos with the same browser - no problems. The same situation has happened in the past, and I don't feel the need to fix it, because I feel it's irrational to expect any browser to work in all cases. That's why I tell my friends and family to forget using a browser with my server.

If it's technically infeasible to build a switch to ban browsers, then oh well, but it would be nice to have.

And for anyone wondering, blocking URI paths that do not contain "/emby" works perfectly well to effectively ban browser access for anyone casually checking to see if it will connect. It won't stop your mom from hacking her way in, but she's probably not going to do that.

[visproduction 332]

CS,

If you really don't like Web access to be used, then just turn off all web using the advanced css style.  Set the whole page div display to none or something similar.  You could also update an announcement to users if they do try to login via web, to just go get some other app.  The dashboard admin gives you an option to include text on the login page.  Finally, just tell your members to access in whatever way you prefer when they join.  Emby is designed for a small group for personal use.  I would think telling your members how you want them to sign in should be fairly easy to do.

[dcook 303]

39 minutes ago, visproduction said:

CS,

If you really don't like Web access to be used, then just turn off all web using the advanced css style.  Set the whole page div display to none or something similar.  You could also update an announcement to users if they do try to login via web, to just go get some other app.  The dashboard admin gives you an option to include text on the login page.  Finally, just tell your members to access in whatever way you prefer when they join.  Emby is designed for a small group for personal use.  I would think telling your members how you want them to sign in should be fairly easy to do.

I have told them, but I still get random browsers showing up in my devices list, that is why I thought it would be good to have an option to disable it, since I never use it.

Would you have an example of the CSS code to put in order to display a message:  "Browser access is disabled"

[C.S. 95]

1 hour ago, visproduction said:

CS,

If you really don't like Web access to be used, then just turn off all web using the advanced css style.  Set the whole page div display to none or something similar.  You could also update an announcement to users if they do try to login via web, to just go get some other app.  The dashboard admin gives you an option to include text on the login page.  Finally, just tell your members to access in whatever way you prefer when they join.  Emby is designed for a small group for personal use.  I would think telling your members how you want them to sign in should be fairly easy to do.

Thanks for the suggestion, but that's all a bit more involved than just blocking any URI without "/emby" in it. That, and I do use the web interface for my own admin duties while logged in locally. I actually like the web interface for everything but playback.

Everything is fine the way it is - I'm just saying a built-in magic switch to disable browser access on a user level wouldn't be a useless thing.

[crusher11 1135]

1 hour ago, dcook said:

I have told them, but I still get random browsers showing up in my devices list, that is why I thought it would be good to have an option to disable it, since I never use it.

Would you have an example of the CSS code to put in order to display a message:  "Browser access is disabled"

Again: why does it matter? 

[C.S. 95]

I think I know what we need. (This is probably already requested but I haven't searched.)

We already have the ability to whitelist devices on the user level. I've always thought this is kind of useless and a little bit mean, because why should I ever want to restrict my friend to his living room TV? Doesn't make sense, so I've never done that. And if Joe wants to trade his roku for a better roku, there's really no good reason for me to be throwing road blocks at him. Whitelisting devices is much too granular, imo.

But let's say for whatever reason I absolutely hate Apple, and I decide I don't want their crap connecting to me. This is where it would be nice to be able to whitelist apps instead of devices.

Something like...
Enable access for:
[x] Roku
[x] Android
[x] AndroidTV
[  ] MacOS
[  ] iOS
[x] Samsung
[x] LG
[x] Web

Is that feasible? I don't know but it makes more sense to me than whitelisting devices. Does anyone here ever whitelist by device? I'd really like to know how often that feature is used and why.