Jump to content

User data on toggling server


EduardoSantos

Recommended Posts

EduardoSantos

Hi,

 

New to the AndroidTV app. Very good work, good ideas and some very beautiful screens. My regards to developers.
Is there a means to snapshot from Emby's the current screen? That would make it a lot easier to post issues here...

 

Anyway, this issue relates to the toggling server mechanism.

I do not use Emby Connect so this is about direct connections.

When toggling from one server to another the app seems to forget user data (name/password) already provided.

I have to re-enter it on each and every toggling to already known servers.

 

Also, but seems of least importance, on the toggling screen servers are presented with their name (url) but with the LAN IP address below.
This is kind of akward when some servers are remote.

I tried to set LAN parms on server configuration but it the app still shows the LAN IP.

Though that does not prevent actual connections it could be a security issue...

Link to comment
Share on other sites

Hi.  The LAN IP would only be accessible on  your LAN.  That's why we show that and not the remote one.  That is displayed only as a "clue" as to which server it is.  It is purely informational.

 

As for remembering credentials between logins, you could accomplish this with Connect or, if local, then you could not require passwords on your LAN.

Link to comment
Share on other sites

EduardoSantos
Scenario is one local server and some remote,

I understand Emby Connect could circumvent the problem and will give it a shot. 

 

Just reported as a means to get it to work on a future release.

It does not have real impact to me.

But I must say exposing an internal/invalid remote address on another LAN really seems a security issue. Don't remember seeing this elsewhere.

 

@@pir8radio may have some input.

Link to comment
Share on other sites

But I must say exposing an internal/invalid remote address on another LAN really seems a security issue. 

 

How so?  We can consider removing it but I fear people will complain about us removing things :).

Link to comment
Share on other sites

EduardoSantos

Well...

 

For remote servers app could present just the URL and, maybe, the external valid IP below it.

 

Once this external valid IP is the real connection parm, it has an additional value to the end user as a means to check to what IP address the app resolved the URL.

To my point of view, internal routing from the external IP to the actual Emby server is server's admin responsability.

 

Humbly suggesting

Link to comment
Share on other sites

Displaying the external IP address could be a potential security risk as people post screen shots or just walk by your screen/device so that's why we show the internal one.

 

Again it is just a clue to further identify a server.  An argument can be made that it isn't really necessary (until we take it out and someone says they were using it to identify a server :)).

Link to comment
Share on other sites

pir8radio

 

Scenario is one local server and some remote,
I understand Emby Connect could circumvent the problem and will give it a shot. 
 
Just reported as a means to get it to work on a future release.
It does not have real impact to me.
But I must say exposing an internal/invalid remote address on another LAN really seems a security issue. Don't remember seeing this elsewhere.
 
@@pir8radio may have some input.

 

 

 

Guess I don't follow the issue...   When you list the "remote" servers in the android app it shows the LAN ip of the remote server?     Pretty sure you can bind the server to 127.0.0.1 and it will hide the LAN address from the remote clients.       But exposing a LAN address isn't really a security issue unless they can get through your firewall, but then a quick scan will show all of the LAN addresses in that case anyway.      You are more than welcome to test my server on your android device, just click my avatar.     See what "lan" ip you see....   you shouldn't see one.  

 

You can test by going to your server ip/domain name    yourserver.com/emby/system/info/public

Link to comment
Share on other sites

EduardoSantos

Well, I did not know that "yourserver.com/emby/system/info/public" would provide specific info on internal IP addressing.

 

That seems very awkward to my understanding of security policies and I agree exposing it on the interface will bring no additional harm.

 

I really though all internal re-routing from incoming packages should rely on router and it's NAT policies.

Binding to 127.0.0.1 seems a very good practice but it will only circumvent a security weakness that should not exist.

 

I may be wrong on considering exposure of an internal IP to be a risk. I will try to learn more on this.

Link to comment
Share on other sites

We'll eventually be removing that information, but keep in mind, you have to already know the address to get there in the first place.

Link to comment
Share on other sites

EduardoSantos

We'll eventually be removing that information, but keep in mind, you have to already know the address to get there in the first place.

 

Sorry but that does not seem to be true.

This info is about internal LAN addressing.

 

External app does not need to know it in order to connect to the server.

It will connect using just server's port and the URL/name (or external valid IP).

 

As promised I will gather info on this but now it really seems a big risk exposure.

Never heard about a server publicizing it's internal LAN IP address.

Link to comment
Share on other sites

pir8radio

Sorry but that does not seem to be true.

This info is about internal LAN addressing.

 

External app does not need to know it in order to connect to the server.

It will connect using just server's port and the URL/name (or external valid IP).

 

As promised I will gather info on this but now it really seems a big risk exposure.

Never heard about a server publicizing it's internal LAN IP address.

 

 

I still dont think its a security risk, there are only so many lan subnets, and if you were in a position to reach any of them a quick scan would show all of the active addresses...      Like I know your server is either in 192.168.x.x  10.x.x.x or 172.x.x.x   a quick scan of those three networks will populate your network.     

 

anyway i think the original use for the /public is to allow any connecting app, no matter how its attempting to connect, to try the local address first to see if its reachable so that you can stream without transcoding using less server resources.     

 

THIS IS REALLY NO BIG DEAL IF YOU HAVE A FIREWALL...   YOUR CURRENT BROWSER PROBABLY GIVES OUT YOUR LOCAL LAN ADDRESS:  https://www.whatismybrowser.com/detect/what-is-my-local-ip-address

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...