incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ali Lown <...@lown.me.uk>
Subject Most gadgets broken are over SSL
Date Wed, 19 Sep 2012 09:26:01 GMT
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

Mime
View raw message