[libvirt] [PATCH 0/3] Ditch external JavaScript libraries

[Martin Kletzander]

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 or
>
>Can 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 :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190620/54ddfed2/attachment-0001.sig>