Closed Bug 701391 Opened 14 years ago Closed 7 years ago

QMO blog triggers mixed insecure/secure SSL warnings in Chrome

Categories

(quality.mozilla.org :: Website, defect, P3)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Atoll, Assigned: craigcook)

References

Details

https://quality.mozilla.org/events/2011/11/07/firefox-mobile-native-ui-test-day/ Viewing this page in Chrome triggers mixed insecure/secure warnings. I tested in Safari and Firefox, neither of them show a UI warning. I look further and it seems that the QMO theme is hard-coding http: for various resources. Please fix all in-page resources to use https: rather than http:. Here's a list of the http: requests Aurora logged: [08:23:45.903] GET http://quality.mozilla.org/qmo_content/plugins/the-events-calendar/resources/events.css?ver=1.6.5 [HTTP/1.1 301 Moved Permanently 63ms] [08:23:45.905] GET http://quality.mozilla.org/qmo_content/plugins/tubepress/sys/ui/themes/default/style.css?ver=3.2.1 [HTTP/1.1 301 Moved Permanently 69ms] [08:23:45.906] GET http://quality.mozilla.org/qmo_content/plugins/buddypress-group-email-subscription/css/bp-activity-subscription-css.css?ver=3.2.1 [HTTP/1.1 301 Moved Permanently 86ms] [08:23:45.912] GET http://quality.mozilla.org/qmo_content/plugins/the-events-calendar/resources/events.js?ver=3.2.1 [HTTP/1.1 301 Moved Permanently 79ms] [08:23:45.914] GET http://quality.mozilla.org/qmo_content/plugins/tubepress/sys/ui/static/js/tubepress.js?ver=3.2.1 [HTTP/1.1 301 Moved Permanently 142ms] [08:23:45.917] GET http://quality.mozilla.org/qmo_content/plugins/buddypress-rate-forum-posts/css/rating.css [HTTP/1.1 301 Moved Permanently 147ms] [08:23:45.919] GET http://quality.mozilla.org/qmo_content/plugins/degradable-html5-audio-and-video/incl/audio-player.js [HTTP/1.1 301 Moved Permanently 157ms] [08:23:45.920] GET http://quality.mozilla.org/wp-content/plugins/wp-recaptcha/recaptcha.css [HTTP/1.1 301 Moved Permanently 165ms]
Craig, this needs to be fixed in the theming. Fallout from forcing https this week.
Assignee: nobody → craigcook.bugz
These are all the result of plugins loading additional resources, but none of those plugins hard-code http://, they're just using the site address variable from the database. We're forcing https on the server-side but hadn't yet updated the URL in general settings, so some plugins were still outputting the old URL. So I've updated the site URL, but I'm still seeing mixed content warnings and 301s for all the same files. I suspect it's just aggressive caching of the HTML output and it may clear itself up momentarily. We should flush the cache when we push our other updates this afternoon, and if we're *still* seeing mixed content after resetting the cache, then it may be some other issue and we'll have to investigate further. I'll keep this bug open for now since I'm not yet certain this fixes it. Fingers crossed...
Blocks: 684867
This is blocking our Mozmill tests because of this unexpected modal dialog. Can we please get this fixed in the short term?
Severity: normal → major
OS: Mac OS X → All
Hardware: x86 → All
If it could be "fixed in the short term," it would already be fixed! Craig has been looking at using a plugin that forces https on all things because nailing down the source of this has been problematic. I'm wondering why we have Mozmill tests relying on QMO instead of mozqa.com. We shouldn't rely on a (kinda sorta) third party website for Mozmill tests.
(In reply to Al Billings [:abillings] from comment #4) > I'm wondering why we have Mozmill tests relying on QMO instead of mozqa.com. > We shouldn't rely on a (kinda sorta) third party website for Mozmill tests. Hi, to help prevent MULTIBUG, is there a bug # for this described problem with QMO/MozQA? It seems reasonable enough, but probably needs to be separated from this http/https bug if any action is desired.
Priority: -- → P3
This was fixed at some point.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.