On Wed, Jun 19, 2019 at 06:24:36PM +0100, Daniel P. Berrangé wrote:
On Wed, Jun 19, 2019 at 05:22:56PM +0200, Martin Kletzander wrote:This is a response to all the discussions (mainly) other people had about all the JS code we're currently using, bundling, etc. I would love some feedback on whether we can work on any of the solutions for getting rid of that external proxy. We would have to: - either have our own proxy,Ideally we'd not use any proxy imho
I agree with that.
- send a 'Access-Control-Allow-Origin' header from the libvirt.org server to allow fetching the atom.xml orCan you elaborate on this ? This is something we'd need to set on the libvirt.org httpd config, to allow it to access atom.xml from the planet.virt-toos.org server ?
The reason why we cannot fetch it directly is because of Same-origin policy [1] CORB (Cross-Origin Read Blocking). In order to avoid XSS (Cross-site scripting) the page is only allowed to access Same-Origin URIs (there are exceptions, I'll get to that). If a resource from different origin needs to be fetched, then the server side needs to be set up for CORS (Cross-Origin Resource Sharing [2]). With that the server sends the Access-Control-Allow-Origin (and other Access-Control-Allow-*) headers that will restrict what resources can the page load and how. For our use case it would be enough to set these, I believe (as more restrictive is better): Access-Control-Allow-Origin: "https://planet.virt-tools.org"; Access-Control-Allow-Methods: "GET" On how to enable these, there is a lot of stuff on the net you can find, but the easiest info is probably here: https://enable-cors.org/server.html There are also some caveats or things people tend to forget (like enabling mod_headers on apache in order to make `Header set` directive work): https://awesometoast.com/cors/ This would be the easiest, cleanest, safest <add other superlatives> way to do that. The JS code would also be smaller and nicer, there would be no need for the condition on whether to call fetchRSS() or not as that would be controled by the server (nothing would be allowed when the file is opened locally and if someone uses a server on localhost (or even hosting our page somewhere else) they can select themselves if they want to allow this or not.
I can change libvirtd.org httpd as needed in general.- be providing JSONP access to the RSS feed on virt-planet.Again any more details on what this would imply ? The planet web server is just running centos7 httpd container in openshift: https://libvirt.org/git/?p=virttools-planet.git;a=blob;f=openshift/templates/virttools-planet.json;h=28f162f43a1cf9b7d437981f7b941d0bf3da60e7;hb=HEAD#l208
This is one of the exceptions for which you do not need to setup CORS, JSONP is used to request JSON data in a certain way. It is what I am doing here, what jQuery's .json does, etc. Basically from JS you add <script src="<your_uri_here>?callback=<name>"/>, that is allowed to come from different origins, the server responds with a JS code that gets "evaluated" (too many details about this, I don't even know most of them, but basically you're not parsing it and you are hoping the server does not send you malicious JS). There would have to be a special code that exposes the atom.xml in the JSONP format, I don't think it's worth working on that, though. [1] https://en.wikipedia.org/wiki/Same-origin_policy [2] https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
