865381 - Mixed active content (scripts and css) on openbadges.org

Status: RESOLVED FIXED

(Websites :: openbadges.org, defect)

Description

[Tanvi Vyas[:tanvi]]

Mixed Active Content is blocked by default for users of Firefox 23+.  We are filing bugs for all Mozilla affiliated websites that have Mixed Content (master tracking bug is 843977).

Mixed content is when http content is present on https pages.  Please remove mixed content from openbadges.org.  If the mixed (active) content is not removed by August (when Firefox 23 hits stable), then openbadges.org will be broken when user's first visit the site.

On openbadges.org's homepage, I see the following two resource loads that are blocked:
* Blocked loading mixed active content "http://openbadges.org/wp-content/themes/openbadges2/media/css/core.min.css?ver=2.0" @ https://openbadges.org/
* Blocked loading mixed active content "http://openbadges.org/wp-includes/js/jquery/jquery.js?ver=1.8.3" @ https://openbadges.org/

Changing these links to "https" will resolve the issue (at least for the homepage).

If you need more information about this, I am happy to help.  You can also see this blog post for more details: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/



+++ This bug was initially created as a clone of Bug #843977 +++

Comment 1

[Adam Muntner [:adamm] (use NEEDINFO)]

I'm on the web app security team, tracking the dependencies for the overall mixed content bug, 843977.

There hasn't been any activity on this bug id lately, who is working on it, if anyone?

Comment 2

[Chris More [:cmore]]

Ross: ^^

Comment 3

[Ross Bruniges [:boozeniges]]

Similar to the Webmaker team the Badges team have been super busy recently preparing for a big launch of a campaign that they're working on but I'll add the PM to the CC for his input. I'll also file a couple of bugs that I think when fixed should help solve things...

Comment 4

[Adam Muntner [:adamm] (use NEEDINFO)]

Thanks for opening the ticket. When can you guys get this on your calendar?

Comment 5

[Adam Muntner [:adamm] (use NEEDINFO)]

Just following up - the new FF beta has mixed content blocking enabled, this is pretty much a dogfood issue.

Comment 6

[Ben (:bensternthal)]

I think this is resolved by the site redirecting to http and not having https.

Going to https://openbadges.org

HTTP/1.1 302 Found
Content-Type: text/html; charset=iso-8859-1
Date: Wed, 03 Jul 2013 22:34:51 GMT
Location: http://openbadges.org/

So no https = no mixed content blocker.

Comment 7

[Ben (:bensternthal)]

Based on the above I am resolving. In the future if this site supports https and has issues we can re-open.

But for now the site appears to be http only.

Comment 8

[Adam Muntner [:adamm] (use NEEDINFO)]

Thank you Ben!

Comment 9

[Tanvi Vyas[:tanvi]]

Not all pages redirect to the HTTP version.  Reopening:

https://community.openbadges.org/

Comment 10

[Ben (:bensternthal)]

Ross:

Can you provide a date when this will be resolved. This will be going into release FF Aug 6.

Comment 11

[Ben (:bensternthal)]

Andrew

I was just informed that Ross is no longer with the company. I am trying to find an owner to fix community.openbadges.org. It is currently broken in IE & Chrome due to mixed content and will be broken on FF come aug 6.


Is this something you can directly fix (found you via github commits), if not can you suggest someone who could?

Comment 12

[JP Schneider :jp]

I've setup a redirect for https-->http.
Moving forward, we've discussed moving the other direction.

Comment 13

[Andrew Hayward [:arhayward]]

I think this can now be closed, based on JP's actions.

Ben, can you confirm that this is sufficient?

Comment 14

[Ben (:bensternthal)]

Redirect looks ok. This technically solves the problem of the site loading in IE, Chrome and now Firefox.

Agree that HTTPS is still the better solution but nice to have the site loading now :)

Comment 15

[Zarro Boogs]

This is a colossal pain. If I'm understanding this correctly, this kills a project I worked a long time on. 

I have written a bookmarklet-based research tool. This bookmarklet calls a page hosted either on a user's own server or on a public server of the user's choosing. Now, that page must be hosted on an https server, or the bookmarklet will not work on pages on websites that default to https, such as facebook or google. Since the tool was primarily intended to be used on facebook, this blows the whole project out of the water. Even if I went to the trouble & expense of getting my own SSL cert, I couldn't distribute the project anymore, because it wouldn't work for anyone who didn't have their own cert, which it's a total crapshoot as to whether a given small-time personal domain owners will or won't don't. 

Developers shouldn't make iron-clad, inflexible security decisions for the user if they limit usability. Whoever made this design decision obviously didn't think through the use cases thoroughly enough.

Comment 16

[Zarro Boogs]

Belay the above. I didn't realize it's only Javascript... it wasn't my page, it was that my page was calling jQuery via http instead of https.

Comment 17

[Zarro Boogs]

And, belay that retraction. My fixes from two weeks ago no longer work. Apparently in FF 25 this "feature" was changed again so that now *all* content called in an iFrame on an https page must also be hosted on an https server. My project is dead in the water, many months of work down the drain.

Comment 18

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

David, this is the wrong bug for discussion your issue. This bug is about mixed content on a specific Mozilla website.

Please join the https://lists.mozilla.org/listinfo/dev-security mailing list and explain your situation there. If your tool is open source, or if you have any kind of public demo of it, please include a link in your email.

Comment 19

[bugcon]

(In reply to Tanvi Vyas [:tanvi] from comment #9)
> Not all pages redirect to the HTTP version.  Reopening:
> 
> https://community.openbadges.org/

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=861847

It seems community.openbadges.org now redirects to http but the (upcoming?) site uses https: https://beta.openbadges.org/

Comment 20

[JP Schneider :jp]

Those are two separate applications.

The first you mention is Wordpress blog outlining the uses for Openbadges.  Beta, which is actually https://backpack.openbadges.org, is a different application for displaying ones badges.