incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ali Lown <a.lo...@gmail.com>
Subject Re: Most gadgets broken are over SSL
Date Thu, 20 Sep 2012 09:29:02 GMT
I agree that the gadgets need to be stored with the Apache Wave
implementation, so that each server hosts the required XML (and CSS, JS,
images etc.) files needed.
(This should be ok for federation as long as the gadgets remain fully
accessible from all IPs)

This would require adding the ability to serve arbitrary files from a
'gadgets' folder (perhaps mapped to
http://waveserver.com/gadgets/[gadgetname]/[filename].[xml,css,js,png,jpg].

For permitting federation between SSL and-non SSL servers, we would need to
make this URL available over both irrespective of the state of the wave
server. (Though any real server should be over SSL anyway).
For this to be possible, as part of the WIAB installation, we would have to
generate valid CA signed certificates simply for serving the gadgets over,
in which case there is no reason to _not_ have the wave server over SSL as
well.
On 19 Sep 2012 12:07, "Bruno Gonzalez" <stenyak@gmail.com> wrote:

> I have no idea about all these issues, but given the problems (SSL on the
> one hand, and 404s after a while on the other hand), it seems logical to me
> that Apache Wave keeps a local non-expiring cache of whatever gadgets are
> used by all its waves. Would that be technically possible in all cases?
>
> This way, you can be sure you'll be able to read your waves not only today,
> but also a year (or five) from now, without losing information on the way
> because some unknown company has closed doors (and they provided some
> gadgets).
>
>
> On Wed, Sep 19, 2012 at 12:50 PM, Jérémy Naegel <jeremy.ngl@gmail.com
> >wrote:
>
> > I don't know much about SSL but, on a related note about XML files being
> > stored on third party servers and about handling this in the long term,
> has
> > I see it, a big part of the problem is that, with time, some of the XML
> > files tend to disappear because their original authors stop hosting them.
> >
> > For example, 3 gadgets on the actual jsongadgets.json file have already
> > disappeared since the last commit (Google Fight!, Travel WithMe and
> Hostel
> > WithMe)... So, my feeling is that backups of the XML files (and maybe
> also
> > of the gadgets' thumbnails pictures) should be hosted by a dedicated Wave
> > project to ensure that they're here to stay.
> >
> > +Jérémy <https://plus.google.com/u/0/110860203879684078598>
> >
> >
> >
> > On Wed, Sep 19, 2012 at 11:26 AM, Ali Lown <ali@lown.me.uk> wrote:
> >
> > > Chrome seems to have changed its default security policy again in the
> > > last few versions (I am not sure exactly when).
> > >
> > > Previously, when the gadget was attempted to be load without SSL,
> > > whilst the server was running under SSL, Chrome would present a bar at
> > > the top of the screen to ask if this is ok. Until you accepted it the
> > > gadget would appear 'broken'.
> > >
> > > More recently, Chrome is now silently blocking this 'insecure'
> > > requests so the gadget immediately appears 'broken', and a user is
> > > unable to bypass this (without starting chrome with a special command
> > > line flag, which is not a valid workaround).
> > >
> > > There seem to be 3 different servers involved in loading a gadget
> > > successfully:
> > > 1) The Wave server hosting the wave
> > > 3) The server hosting the gadget xml file
> > > 2) Some Google interim server (googleusercontent.com) though which the
> > > gadget data seems to be loaded.
> > >
> > > If (1) has SSL off, (3) has SSL off then the gadget loads
> > > If (1) has SSL on, (3) has SSL off then the gadget fails to load
> > > (2) always seems to use the same settings as (1) so isn't an issue.
> > >
> > > I am not sure how we can handle this since (most of the time) the
> > > actual gadget xml file is stored on some third party server (which
> > > rarely has SSL support enabled).
> > >
> > > In the mean-time, for the gadgets I am interested in, I will be
> > > hacking the jsongadgets.json file (and the gadget xml file) to point
> > > to my locally (and securely) delivered xml (and supporting json/css)
> > > files.
> > >
> > > In the longer term, I am uncertain how we should handle this. Thoughts?
> > >
> > > Ali
> > >
> >
>
>
>
> --
> Saludos,
>      Bruno González
>
> _______________________________________________
> Jabber: stenyak AT gmail.com
> http://www.stenyak.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message