incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Gonzalez <sten...@gmail.com>
Subject Re: Most gadgets broken are over SSL
Date Wed, 19 Sep 2012 11:06:04 GMT
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