1050478 - telemetry-dash doesn't work over HTTPS

Status: RESOLVED FIXED

(Webtools Graveyard :: Telemetry Server, defect)

Description

[Benjamin Smedberg]

I noticed that I was using telemetry-dash over HTTP, and I wasn't sure how risky that was. So I tried loading https://telemetry-dash.mozilla.org/.

This has a certificate, but it doesn't work because of mixed-content warnings:

Blocked loading mixed active content "http://netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css"[Learn More] telemetry-dash.mozilla.org
Blocked loading mixed active content "http://ajax.aspnetcdn.com/ajax/jquery.validate/1.11.1/jquery.validate.min.js"[Learn More]

Can that be fixed?

Comment 1

[Jonas Finnemann Jensen (:jonasfj)]

The code lives here:
https://github.com/mozilla/telemetry-server/tree/master/http/analysis-service

Mostly this amount to fixing the templates to load resources over HTTPS instead of HTTP.
The CDNs used already seems to support HTTPS, so there really no excuse here.

Note, it might be smart to host the libaries instead of including them from CDN. It's just less maintenance.

By the way, you'll probably need mreid to deploy this, getting cloudformation updates right can be a bit tricky.
Last time we did for the other analysis framework we ended up with a renegade nodee eating all of our tasks.
Though it might be sufficient to do "make clean; make put" and then murder the existing node. If so you should probably murder it an extra time a few hours later, just for good measure :)
I know lol, but serious there could be eventual consistency issues, because code is stored on S3. Of course you can just check if changes where deployed...
(It's running in an auto-scale group of one, so if you murder it, it'll probably come back up and download the new code deployed with make put).

Extra note, maybe we should consider redirecting to HTTPS from within the server. That would be a really nice feature.

Comment 2

[Mark Reid [:mreid]]

I deployed the changes to use relative URI schemes and still logging in via "https://telemetry-dash.mozilla.org/" does not work.

Comment 3

[Mark Reid [:mreid]]

Benjamin, any ideas why the login still isn't working?

Comment 4

[Jonas Finnemann Jensen (:jonasfj)]

My guess is that the python persona plugin doesn't know that it is behind https, because this is handled by a proxy. So the persona server returns an unexpected reply... More investigation needed, typically this shows up on logs..

Comment 5

[Benjamin Smedberg]

I wasn't able to figure anything useful from client-side debugging.

Comment 6

[Mark Reid [:mreid]]

Based on a pointer from Jonas, I modified the upstream browserid package to handle the "X-Forwarded-Proto" header. Since the python server was behind a load balancer (which was doing the ssl termination), the client was seeing a URI scheme of "https", but the server was seeing "http".

The change has been deployed, and logging in via https://telemetry-dash.mozilla.org now works for me.

See https://github.com/mozilla/telemetry-server/pull/78 
and
https://github.com/garbados/flask-browserid/pull/21
for more details.