url verification

[quickmic 1372]

Please don't verify the url-syntax the way as it's implemented.

I run emby behind a proxy with my own password protection.

Therefore I call th emby server with e.g. https://username:password@website.tld

That's a vaild URL call and works!

 

btw, not sure if other clients are affected as well. Emby for kodi accepts that syntax url at least via editing the settingsfile directly. Not tested via GUI.

 

thx

 

[Luke 37185]

Hi, can you elaborate more on exactly what your issue is? thanks !

[quickmic 1372]

Hmm, not sure how to describe this even better.

It seems the android client has a verification procedure in place, which scans for valid server-urls.

 

...I have a additional password protection (like htaccess) configured, cause I wanna be absolutely save, when accessing emby from internet site.

Therefore I run emby behind an apache proxy.

The URL "https://username:password@website.tld" or "https://username:password@myembyserver.com" sends the user/password for the first barrier (apache proxy) via url link directly, but I guess the syntax is blocked by some sort of check-routine by the android client.

 

I can verify again when I'm at work, but I don't think my tests wasn't appropriate.

Edited June 14, 2017 by quickmic

[Luke 37185]

You mean on the screen where you enter a server address?

[quickmic 1372]

My emby server-address... Android client... "change server" -> "Add server" -> now I can enter my  "Host" (hostname) and Port

Edited June 14, 2017 by quickmic

[quickmic 1372]

https://freelancetek.com/blog-pics/EMBY-media-server-Part-5-Use-Emby-mobile-app/8.jpg

[Luke 37185]

We are not artificially preventing you from entering that, but the fetch API that we are using to execute http requests does not fully support it and from the comments here it sounds more like they want to just forbid it altogether:

 

https://github.com/whatwg/fetch/issues/26

 

I can also tell you that we have never tested this, therefore as of today what you are trying to do is not supported.

[shorty1483 453]

Hi, can you elaborate more on exactly what your issue is? thanks !

 

I guess @@quickmic (correct me if I'm wrong) uses some sort of basic_auth module with his apache to have more security. With a browser, this works using the url he mentions, but not the Apps. 

 

I would also be a fan of this.

[quickmic 1372]

Exactly, I use basic_auth with apache and it works fine with kodi plugin.

<VirtualHost *:443>
        ServerName myembyurl.net
        ServerSignature off
        SSLProxyEngine On
        SSLProxyVerify none
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
        SSLProxyCheckPeerExpire off
        ProxyRequests Off
        SSLEngine On
        SSLCertificateFile /mnt/storage0/ssl-signed/xxx_certificate.crt
        SSLCertificateKeyFile /mnt/storage0/ssl-signed/xxx_privatekey.pem

        <Proxy *>
                Order Allow,Deny
                Allow from all
                AuthType Basic
                AuthName "RMS-Systems"
                AuthUserFile /var/www-access/htpasswd-kodi
                Require valid-user
                Satisfy all
        </Proxy>

        <Location "/">
                ProxyPass http://192.168.0.203:8096/emby
                ProxyPassReverse http://192.168.0.203:8096/emby
        </Location>

        #Emby
        <Location /emby>
                ProxyPass http://192.168.0.203:8096/emby
                ProxyPassReverse http://192.168.0.203:8096/emby
        </Location>

        <Location /embywebsocket>
                ProxyPass http://192.168.0.203:8096/embywebsocket
                ProxyPassReverse http://192.168.0.203:8096/embywebsocket
        </Location>
</VirtualHost>
<VirtualHost *:80>
        ServerName myembyurl.net
        Redirect permanent / https://myembyurl.net/
</VirtualHost>

Edited June 14, 2017 by quickmic

[Luke 37185]

To be honest i'm surprised that it works in the browsers.

[quickmic 1372]

That "trick" works almost everywhere in case of urls with AuthType Basic. btw, "wget" is also functional with this syntax.

Edited June 14, 2017 by quickmic

[quickmic 1372]

Last comment on this topic.

Emby "m3u-tuner" (live TV) also accepts such urls. EPG as well.

[pünktchen 1259]

I'm also interested in this kind of security/authentication.

[pir8radio 1292]

Just to clarify, the original poster is authenticating to a proxy server   then most likely being presented with the actual emby login screen as a second step.   So you would enter user:pass@domain.com (first auth) then you get the emby screen where you have to login a second time.    This is not a different way to login to emby using user:pass@domain.com ONLY.

 

His issue is that the apps do not accept the "user:pass@"  part of the url, which is understandable most browsers are dropping this support now days.  See URL ENCODING : https://en.wikipedia.org/wiki/Basic_access_authentication#URL_encoding 

 

Have you found an issue with the emby login security?     Just curious.

Edited June 14, 2017 by pir8radio

[quickmic 1372]

which is understandable most browsers are dropping this support now days.

 

I ran a view tests with firefox, google chrome and chromium. user:password is accepted at least under the following circumstances:

http (plaintext) to a intranet url (eg. 192.168.0.x)

https (encrypted) to any destination

http (plaintext) to public url, not sure here. It was not accepted in my case, but my proxy immediately redirects to https. So could be blocked cause of http or cause of redirection.

 

I also checked the german wikipedia, which is a bit more detailed in case of this specific security issue. Of course if you use http it's a security nightmare. In case of using https, the user:password is encrypted via ssl before transmission and should be save.

Imho the RFC 8986 doesn't deprecate this way of login in general. It deprecates plaintext passwords which is not the case if I use ssl and this sounds reasonable.

Edited June 15, 2017 by quickmic