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,

 - send a 'Access-Control-Allow-Origin' header from the libvirt.org server to
   allow fetching the atom.xml or

 - be providing JSONP access to the RSS feed on virt-planet.

I do not have access to any of the infrastructure, so I cannot say if any of
that is possible.  It is definitely possible from the technical point of view.

Martin Kletzander (3):
  docs: Use our own implementation for fetching the RSS data
  docs: use case sensitive javascript
  docs: Remove unused JS libraries

 docs/Makefile.am            |  6 +----
 docs/index.html.in          | 16 ------------
 docs/js/jquery-3.1.1.min.js |  4 ---
 docs/js/jquery.rss.min.js   | 11 ---------
 docs/js/main.js             | 49 ++++++++++++++++++++++++++++++++++++-
 docs/js/moment.min.js       |  7 ------
 6 files changed, 49 insertions(+), 44 deletions(-)
 delete mode 100644 docs/js/jquery-3.1.1.min.js
 delete mode 100644 docs/js/jquery.rss.min.js
 delete mode 100644 docs/js/moment.min.js

-- 
2.21.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

>  - 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 ?

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


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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, 2019-06-20 at 10:04 +0200, Martin Kletzander wrote:
> 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:
> > > 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.

Same here.

With that in mind, this is a pre-existing issue with our blog roll
implementation, that we're just making explicit with this change
where it was hidden inside jquery.rss before, so I don't think it
should be blocking this series which implements a strictly better
solution than the current one.

Let's get this merged, release v5.5.0 with no third-party JavaScript
libraries, and then work on removing our reliance on feedrapp as a
follow up.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, Jun 20, 2019 at 10:29:10AM +0200, Andrea Bolognani wrote:
>On Thu, 2019-06-20 at 10:04 +0200, Martin Kletzander wrote:
>> 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:
>> > > 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.
>
>Same here.
>
>With that in mind, this is a pre-existing issue with our blog roll
>implementation, that we're just making explicit with this change
>where it was hidden inside jquery.rss before, so I don't think it
>should be blocking this series which implements a strictly better
>solution than the current one.
>
>Let's get this merged, release v5.5.0 with no third-party JavaScript
>libraries, and then work on removing our reliance on feedrapp as a
>follow up.
>

Yeah, it's going to take some work.  I mainly misunderstood how it's supposed to
work, so for now I am testing it locally to make sure we really know what to
change and where.  For now the v2 of the clean-up (with hopefully addressed all
things pointed by the reviews) is here:

  https://www.redhat.com/archives/libvir-list/2019-June/msg00957.html

I sent another version because I did some additional clean-ups and we can get a
clear consensus on the state there.

Thanks,
Martin
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, Jun 20, 2019 at 10:04:03AM +0200, Martin Kletzander wrote:
> 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"

As discussed on irc, we actually needed the reverse. planet.virt-tools.org
web server needs to server these headers, allowing libvirt.org. I have now
got the planet.virt-tools.org apache configured todo this correctly I
believe, so please give it a try & let me know if anything else needs
changing on either httpd server.


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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list