#550 closed defect (fixed)
Mixed Content Bug in dojo/src/storage/Browser.js
Reported by: | Owned by: | dylan | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | Core | Version: | 0.3 |
Keywords: | Mixed Media IE | Cc: | [email protected]… |
Blocked By: | Blocking: |
Description
Hey now. I'm a fairly green newbie here and I am getting a "This page contains both secure and nonsecure items" security warning from my webapp in IE.
I am using the latest "kitchen sink" toolkit release 0.2.2. If I remove the inclusion of dojo.js the problem goes away. I found a similar issue about this (http://dojotoolkit.org/pipermail/dojo-checkins/2006-February/004104.html) but by making the suggested change in dojo.js, my problem did not go away.
It looks like the culprit is at line 79 in dojo/src/storage/browser.js which links to a macromedia shockwave site.
This line:
storeParts.push(' codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0"');
will cause a Mixed-Content error in IE if the you are running on a secure server (https). By modifying the line to:
storeParts.push(' codebase="https://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0"');
..the problem goes away.
Just by including dojo.js (0.2.2 Kitchen Sink version) a bare bones HTML file and placing it on a secure server, you should see the error reproduced in IE.
-Sol
Change History (15)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
Suggestion from Sam Foster:
Why not be explicit about what you are matching for:
var protocol = "http"; var regexp = new RegExp?("https:", "i"); if( regexp.test(window.location.href) ) {
protocol = "https";
}
That's some pretty good hunting though Sol, glad you got to the bottom of it.
Sam
comment:3 Changed 15 years ago by
Priority: | highest → normal |
---|
comment:4 Changed 15 years ago by
Owner: | changed from anonymous to Dustin Machi |
---|
comment:5 Changed 15 years ago by
We should see if this still happens with the latest storage refactoring; it looks like the fix is to use the same scheme when loading the SWF files as the parent page has (i.e. use http or https or even file:// if the parent page is using this). I'll try to hit this before the 0.3 release
comment:6 Changed 15 years ago by
Milestone: | 0.3release → 0.3.1 |
---|
Brad didn't make it for 0.3 ... moving to 0.3.1
comment:7 Changed 15 years ago by
Owner: | changed from Dustin Machi to Brad Neuberg |
---|
comment:8 Changed 15 years ago by
Version: | 0.2 → 0.4 |
---|
I don't have a testing environment setup with a secure server to fix this bug and make sure it's fixed; does someone have such an environment? I also don't have the bandwidth right now to hit it; pushing to 0.4.
comment:9 Changed 15 years ago by
Milestone: | 0.3.1 → 0.4 |
---|---|
Version: | 0.4 → 0.3 |
comment:10 Changed 14 years ago by
Owner: | changed from Brad Neuberg to dylan |
---|---|
Status: | new → assigned |
comment:11 Changed 14 years ago by
severity: | normal → blocker |
---|
comment:12 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
A possible fix... I emailed this to the interest list but since there is a ticket I'll post it here as well. I dont see why you could fix this problem by checking the window.location.href
});