Hi.
I’ve got Xibo 1.8.0-rc2 up and running using the Docker images. It’s using pure http though and I want https. If I understand things correctly I can simply edit the apache-config.conf in containers/web-dev and it will overwrite the default one, right? Question is how I get the cert files into the Docker image. I guess I can manually copy them there, but that doesn’t feel like a good idea since they’ll be overwritten when the image is rebuilt. Is there any supported way of doing it?
The same goes for SAML. I haven’t started playing with it yet, but I get the feeling I’ll stumble into the same problem there. I can put the settings in settings-custom.php, but how do I get the needed cert files in?
I’m a newbie when it comes to Docker, so I don’t know how this is usually done, but I guess a general way of getting custom files into the image is needed.
Hi again. I’m just wondering, since I got no replies here: Is it simply the fact that https isn’t supported when using Docker? Seems kinda strange to me since Docker is the recommended installation method for Tempel and https should be recommended as well. There really should be a recommended way of enabling https.
Sorry Daniel - I didn’t see your message - its been busy recently. I agree we need to supply some instructions on how to do this in the documentation.
The docker containers we’ve supplied are non-ssl which is standard practice when using Docker - mostly for the reason you’ve highlighted - getting stuff into the container.
You can and should use SSL for anything public or unsecured, but you need to terminate the SSL connection on your host machine and use a reverse proxy to forward SSL requests into the Docker container. This sounds complicated but is actually quite simple.
You can use any web server you like as the reverse proxy and SSL termination. If you intend to use SAML then you should also make sure you set the X-Forwarded-For information or (preferable) the baseurl in custom-settings.php.
Thanks for your answer. Thing is what I really want to do and completely failed doing is routing all Xibo traffic through our Nexus Hybrid Access Gateway (HAG), which is a solution that essentially provides authentication and SSL (using reverse proxing, rewriting all hostnames on the fly). It was first efter failing that I started trying to configure https on the Xibo server. Maybe with some help I’ll get my original plan working instead.
What happens when I access Xibo through HAG is that everything works fine in the administration gui, but the Windows player completely refuses to do anything useful. The player configuration says everything is ok but the player just shows the splash screen forever. From what I can see with wireshark on the client and tcpdump on the server everything comes through perfectly fine so I can’t for my life understand why it won’t work. Any spontaneous ideas?
What does the client information window show you? (press i on the keyboard). I suspect there will be some errors listed there which might point you/us to the problem.
Ah, that was a key I’d totally missed out on. I’m sorry though, but it didn’t give me anything useful at all (except for the error about XMR, which I simply hasn’t bothered about yet). I guess if there were any errors I’d see them in the lower half of the window?
Check that your default layout is valid in the CMS. Our general recommendation is that it be a simple layout with only a single image (a company logo for example) on it. Your content should all come down as scheduled content.
Ok. One step ahead, but I’m still pulling my hair. I can see in the output from HAG that the xlf file is sent (with an url like xmds.php?file=wlGKjrMNGbiTL37ZxXdCmGHjmSiXRB9o&displayId=2&type=L&itemId=1), but the client still says 0%. I also tried different layouts and it turns out that really simple layouts (containing not more than one region) works. So this problem only occurs when the client tries to show a layout with two or more regions and only if it’s through HAG. Now I’m trying to get my Wireshark to decrypt the traffic so I can see what really happens from the client’s side of view…
One question: I don’t think this is the problem, but I noticed the xlf file is sent with content type text/html although it’s obviously and xml file. Is this a problem in the Apache config in the Docker image or a problem in Xibo itself?
It’ll be whatever Xibo returns I think. I don’t think it will make any difference to the Player what the mime type is. It’s just downloading that file to disk. Only then will it read it.
1.8 series CMS will prevent an invalid layout from being downloaded, so I’d suggest that the layouts that won’t work aren’t valid. For a layout to be valid, it must have 1 or more regions, and all regions must have one or more media items in them.
Well, thing is they work fine when I point the client directly towards the Xibo server, bypassing the proxy (ie plain http). So the problem is not within the layouts as such. Does Xibo do anything different with a layout having multiple regions compared to a layout having only one single region?
Not that I’m aware of. From the Player’s point of view, it’s just a text file with the layout description in it.
The proxy definitely isn’t making changes to the content as it goes through? Putting the Player in audit mode will tell us why the XLF file is being rejected - at a guess if it works otherwise, the final MD5 checksum doesn’t match once it’s been downloaded which suggests something is modifying it en-route.
Yep, the proxy is modifying things. It’s inspecting the traffic, rewriting all hostnames and ip addresses within it. This way the client will never need to know the servers internal name or ip, all references to it is replaced with it’s external name which points to the proxy server. But of course, if the player does md5 checking of stuff it might very well explain why this isn’t working. Do you know exactly which elements it checks?
I still don’t understand though… It’s natural that it swallows for example png files, nothing is changed in those. But I can’t find anything the proxy changes in the xlf file neither… And why does this work for some layout and not others?
Is there any way to turn off the md5 checking completely? It doesn’t seem necessary in this case.
The XLF must not be modified between the CMS and Player, which is why the Player checks it. The file must be delivered exactly as the CMS outputs it.
Please disable that functionality in your proxy server. The Player handles all references to the location of files in the Xibo system so there’s no need for rewriting content there.
I’d imagine if your server is rewriting things it thinks are URLs, it will depend on whether the layout uses resources which the Player will receive as HTML content - with an associated URL. That will reference the Player’s own webserver, and so must not be rewritten.
Your Player should be configured to connect to your reverse proxy. The X-Forwarded-For/X-Forwarded-Proto headers will ensure the backend webserver uses the correct URL in its responses. Your proxy should be adding those in. There’s no need for the reverse proxy to rewrite anything else for this to work.
Yes, that would be the case with a “normal” reverse proxy. This one doesn’t work that way. I’m not enough of an expert to say why, but I think it’s security related (it’s a product used by many big companies and banks). It simply opens one session to the inside resource server (in this case the Xibo server) and another session to the outside client (in this case the Xibo client) and rewrites all trafic so that the client never knows it’s passed through anything, it thinks the outside name is the name of the server (ie no X-Forwarded-For headers). We use it with quite a lot web resources without problem, but if the client start md5-checking the content there will be problem.
Xibo has always worked that way. Your proxy isn’t going to be compatible with Xibo if it actively changes the content passing through it I’m afraid. You’ll need to do SSL termination using a different webserver - nginx or Apache.
Turning off checksumming content isn’t a viable option because then the Player has no way to know if the content was tampered with, or corrupted in transit.
As a side note, SAML definitely won’t work via a proxy as you describe as the webserver running inside the container needs to know what the URL being returned from your IdP is - and if it sees an IP address that isn’t going to match the URL hitting the proxy, and it will be declined.
Well, I guess the only alternative then is to get https on the Xibo server itself going, using a proxy there. I’ll look into that.
I would say though that protection against tampering and corruption is something that belongs in the tcp or ssl layers, not in the application itself, so an option to disable it would be quite reasonable from my point of view.
Anyway, thanks a lot for the time you’ve put down in trying to solve this. Even though it looks like we aren’t going to solve it, the effort is appreciated!
As for SAML (just saw your addition), I think we’ll have to look into that. That’s what this solution is built for though, the HAG acts both as reverse proxy and SAML IdP/SP, so I’m sure it works. I don’t think I have used an internal resource server as SP though, so you might be right.
Unfortunately when you’re dealing with WAN connections, tcp level corruption doesn’t cut it. It’s not uncommon to have files download completely and then fail a checksum, which is why it’s there.
It’s a core tennant of how the Players work and I don’t see us changing that any time soon. I’m really surprised the HAG can’t be told not to rewrite URLs within content (rather than rewriting only the URLs as they are requested). That seems to me to be a far more reasonable mode of operation.
If the IdP is the HAG, then it may work in your scenario, since the call back from the IdP isn’t coming through the proxy and being re-written. In scenarios where we’ve done SAML in Docker, the correct callback URL is crucial otherwise requests will fail, but I’ve never done a configuration where the proxy was a SAML IdP.
To get this working, you could look at running something like this:
Sorry to chime in after a delay - but I am confused as to exactly what HAG would be rewriting in XLF files? Surely it will only be interested in the IP’s it is proxying for - of which there will be 0 in the XLF file.
As a matter of fact, if you are requesting layout XLF files and media through XMDS, the content of the request is base64 encoded anyway. If they are being requested using apache sendfile (which they will be from Docker?) then the contents still wouldn’t contain any URL’s which the proxy should be interested in.
That begs the question - what is HAG actually changing and why? Because it’s not URL’s
Can you inspect the contents of the XLF file output from HAG and compare it to the XLF file stored in the CMS library (mapped out to the Docker host)?
