Closed Bug 337755 Opened 15 years ago Closed 15 years ago
Caller Secure() implementation incorrect
Er... So what I _meant_ to say was: The IsCallerSecure() impl in dom/src/storage/nsDOMStorage.cpp will break for jar:https:// sites. It will also break for other protocols that are secure (imap: can be, for example), but that worries me less. On branch, you probably have to QI to nsIJARURI, etc. On trunk, you can use NS_GetInnermostURI or better yet, imo, add a protocol handler flag for determining whether a given protocol is secure and use NS_URIChainHasFlags.
so does this base secureness determination only on the scheme? sounds like a bad idea to me... what if a protocol can be both secure and insecure, depending on what you negotiate?
IMO, this should use the channel's securityInfo, or something equivalent (docshell's securityUI?)
That might be a good idea... Eg. if we have an https:// URI that includes insecure content (so broken lock icon), I'm not sure we want to treat it as "secure" here.
Yes, long-term we'd want something like that for sure, but that's a rather large change here and to the code related to our handling of secure and mixed https pages. This is a trivial patch that gets us a far bit further than the current code at least.
Complete diff this time, the previous one was a partial change.
Ok, this is the right diff, really.
Attachment #228238 - Flags: superreview?(bugmail) → superreview+
Fix landed on the trunk.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
This is the same as the above change, only it uses nsIJARURI direcly since there is no NS_GetInnermostURI() on the branch.
Attachment #228752 - Flags: approval1.8.1?
This is IMO low-risk enough, even if not extremely high benefit, to take on the branch for 2.0.
Flags: blocking1.8.1? → blocking1.8.1+
Target Milestone: --- → mozilla1.8.1beta2
Fixed on the 1.8 branch.
You need to log in before you can comment on or make changes to this bug.