Closed Bug 337755 Opened 15 years ago Closed 15 years ago

IsCallerSecure() implementation incorrect

Categories

(Core :: DOM: Core & HTML, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8.1beta2

People

(Reporter: bzbarsky, Unassigned)

References

Details

(Keywords: fixed1.8.1)

Attachments

(2 files, 2 obsolete files)

 
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.
Blocks: 335540
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.
Attachment #228236 - Flags: superreview?(bugmail)
Attachment #228236 - Flags: review?(enndeakin)
Complete diff this time, the previous one was a partial change.
Attachment #228236 - Attachment is obsolete: true
Attachment #228237 - Flags: superreview?(bugmail)
Attachment #228237 - Flags: review?(enndeakin)
Attachment #228236 - Flags: superreview?(bugmail)
Attachment #228236 - Flags: review?(enndeakin)
Ok, this is the right diff, really.
Attachment #228237 - Attachment is obsolete: true
Attachment #228238 - Flags: superreview?(bugmail)
Attachment #228238 - Flags: review?(enndeakin)
Attachment #228237 - Flags: superreview?(bugmail)
Attachment #228237 - Flags: review?(enndeakin)
Attachment #228238 - Flags: review?(enndeakin) → review+
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?
Flags: blocking1.8.1? → blocking1.8.1+
Target Milestone: --- → mozilla1.8.1beta2
Attachment #228752 - Flags: approval1.8.1? → approval1.8.1+
Fixed on the 1.8 branch.
Keywords: fixed1.8.1
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.