Webpage with Basic Auth

We have a few Neo-X7-Mini displaying a status page from nagios for our NOC.
For this it needs to do 3 requests, one for the html and then for two images the html page refers too.
Since the servers needs basic auth we create the URL in the webpage-object like this:

https://user:pass@servername

The Xibo android client first tries the HTML without auth, which results in a 401 (auth needed).
Then it tries again with basic auth, success.
When it tries the refered pictures it tries again without basic auth resulting in a 401, but this time it does not retry with auth.

Windows clients and preview from the server interface all work perfectly.

These are the sanitized logs from the webserver.

`2a01::def5 - - [12/Apr/2016:15:50:22 +0200] “GET /nagios/cgi-bin/status.cgi?host=all&servicestatustypes=28 HTTP/1.1” 401 931 “-” “Mozilla/5.0 (Linux; Android 4.4.2; NEO-X7-mini Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Safari/537.36”

2a01::def5 - display [12/Apr/2016:15:50:22 +0200] “GET /nagios/cgi-bin/status.cgi?host=all&servicestatustypes=28 HTTP/1.1” 200 2551 “-” “Mozilla/5.0 (Linux; Android 4.4.2; NEO-X7-mini Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Safari/537.36”

2a01::def5 - - [12/Apr/2016:15:50:22 +0200] “GET /nagios/images/up.gif HTTP/1.1” 401 793 “https://host.webserver.com/nagios/cgi-bin/status.cgi?host=all&servicestatustypes=28” “Mozilla/5.0 (Linux; Android 4.4.2; NEO-X7-mini Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Safari/537.36”

2a01::def5 - - [12/Apr/2016:15:50:22 +0200] “GET /nagios/images/down.gif HTTP/1.1” 401 793 “https://host.webserver.com/nagios/cgi-bin/status.cgi?host=all&servicestatustypes=28” “Mozilla/5.0 (Linux; Android 4.4.2; NEO-X7-mini Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Safari/537.36”
`

Thanks in advance to anyone who can give more insight as to what goes wrong.

Which mode do you have set?

We run a nagios HUD here as part of the test suite and have it set to “Best fit” which works OK for the main page and subsequent resources.

Hi Dan,

It was set to manual, i’ve just tried Best Fit. Restarted the X7 to be sure. Same result.
As a workaround i can serve the two images without authentication. I’d rather not have too…

Thanks, Thomas

We just use the URL

https://username:password@host/nagios/cgi-bin/tac.cgi

That works fine as far as I can see?

Are you running an up to date version of Xibo for Android and the latest 4.4 series firmware from Minix on the devices?

Hi Alex,

Firmware is 4.4.2, Xibo is at 1.7(59)

1.7 R60 has been out for some time - although I don’t think it should make any difference.

What’s the exact setup you have for the webpage media in the layout - ie the URL, all the other settings? I can try those here then.

Clearly you can redact the server name, but the rest of the URL would be helpful.

URL: https://USERNAME:PASSWORD@host.domain.com/nagios/cgi-bin/status.cgi?host=all&servicestatustypes=28

Best Fit
Duration 30
Page Witdh 0
Page Height 0

OK I’ve entered it like that here and I don’t see any broken images. See the screenshot below.

I wonder if that’s a bug in the specific version of the firmware on that device? Are you able to upgrade it to latest?

As far as i know we are at the latest firmware.
At first i suspected our virtualhost config, we do basic auth via radius and restrict on ip. But the problem only surfaces with the android client. Windows client and preview in browser are both ok.

Later this week i’ll try a packet capture on the nagios server to look at the request diffs between windows/android.

We have very little control over what the WebView does in Android. All we do is pass in the URL you give us and then WebView does all the rendering.

It works as far as I can see with standard basic authentication so it may be something in your setup that causes it. Either way I don’t think there’s anything we can do to alter it’s behaviour in this case. You may need to work around it server side if it won’t work any other way.

The reason I think it may be that you have older firmware is that the Chrome version number in your example log is relatively low.