Closed
Bug 968335
Opened 10 years ago
Closed 10 years ago
Expose caller principal to JS-implemented webidl
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla30
People
(Reporter: mt, Assigned: bholley)
References
(Blocks 1 open bug, )
Details
Attachments
(7 files, 2 obsolete files)
5.00 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
2.84 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
2.49 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
4.10 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
10.44 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
4.15 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
4.69 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
JS-implemented webidl is unable to accurately (i.e., securely) determine the principal of the content object that invoked it. Using window.document.nodePrincipal exposes the JS to the chance that navigation could occur, causing this to be spoofed. In C++, this would involve calling GetSubjectPrincipal().
Updated•10 years ago
|
Blocks: ParisBindings
Comment 1•10 years ago
|
||
Updated•10 years ago
|
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Comment 2•10 years ago
|
||
Updated•10 years ago
|
Attachment #8370985 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Blocks: SH-bindings
Assignee | ||
Comment 4•10 years ago
|
||
I've got all the code done for this - I just need to write tests.
Assignee | ||
Comment 5•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=590b4f0d0bff
Assignee | ||
Comment 6•10 years ago
|
||
Still sorting out some weirdness with the build changes for the tests for bug 923904, but we can start getting this reviewed.
Assignee | ||
Comment 7•10 years ago
|
||
Attachment #8374947 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 8•10 years ago
|
||
This patch, and those following, are part of an epic quest to make this API work properly despite the fact that we don't yet have GetEntryGlobal. See the comment a few patches forward.
Attachment #8374948 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 9•10 years ago
|
||
This will let us ask whether the AutoCxPusher is stack-top.
Attachment #8374949 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 10•10 years ago
|
||
This will allow us to downcast from a stack entry to an AutoEntryGlobal, and thereby get at the AutoCxPusher.
Attachment #8374950 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 11•10 years ago
|
||
Attachment #8374951 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 12•10 years ago
|
||
Attachment #8371028 -
Attachment is obsolete: true
Attachment #8374952 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 13•10 years ago
|
||
Intentionally not flagging these for review until we get the build issues sorted.
Assignee | ||
Comment 14•10 years ago
|
||
Hopefully sorted out the packaging issues: https://tbpl.mozilla.org/?tree=Try&rev=9480abb18974
Assignee | ||
Comment 15•10 years ago
|
||
Comment on attachment 8374954 [details] [diff] [review] Part 7 - Tests. v1 All green now. Flagging bz.
Attachment #8374954 -
Flags: review?(bzbarsky)
Comment 16•10 years ago
|
||
Comment on attachment 8374947 [details] [diff] [review] Part 1 - Add accessors to the script settings stack entries themselves, not just the globals. v1 r=me
Attachment #8374947 -
Flags: review?(bzbarsky) → review+
Comment 17•10 years ago
|
||
Comment on attachment 8374948 [details] [diff] [review] Part 2 - Add an API to determine if a given AutoCxPusher corresponds to the stack-top cx push. v1 r=me
Attachment #8374948 -
Flags: review?(bzbarsky) → review+
Comment 18•10 years ago
|
||
Comment on attachment 8374949 [details] [diff] [review] Part 3 - Use an AutoCxPusher directly in Auto{Entry,Incumbent}Global. v1 r=me
Attachment #8374949 -
Flags: review?(bzbarsky) → review+
Comment 19•10 years ago
|
||
Comment on attachment 8374950 [details] [diff] [review] Part 4 - Make Auto{Entry,Incumbent}Global inherit ScriptSettingsStackEntry. v1 Do we want to mark these as stack classes while we're here?
Attachment #8374950 -
Flags: review?(bzbarsky) → review+
Comment 20•10 years ago
|
||
Comment on attachment 8374951 [details] [diff] [review] Part 5 - Implement GetCallerPrincipalOverride. v1 How cheap is GetSubjectPrincipal? We're going to do it on every JS-implemented WebIDL call/get/set, right? >+ callSetup += str(bool(isJSImplementedDescriptor(self.descriptorProvider))).lower() callSetup += toStringBool(isJSImplementedDescriptor(self.descriptorProvider)) r=me modulo that performance concern.
Attachment #8374951 -
Flags: review?(bzbarsky) → review+
Comment 21•10 years ago
|
||
Comment on attachment 8374952 [details] [diff] [review] Part 6 - Implement Cu.getWebIDLCallerPrincipal. v1 r=me
Attachment #8374952 -
Flags: review?(bzbarsky) → review+
Comment 22•10 years ago
|
||
Comment on attachment 8374954 [details] [diff] [review] Part 7 - Tests. v1 r=me
Attachment #8374954 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 23•10 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #19) > Do we want to mark these as stack classes while we're here? We could, but we may need to undo that again with bug 971673. I'd rather sort that out first. (In reply to Boris Zbarsky [:bz] from comment #20) > How cheap is GetSubjectPrincipal? We're going to do it on every > JS-implemented WebIDL call/get/set, right? Pretty cheap. It boils down to: nsJSPrincipals::get(GetCompartmentPrincipals(GetContextCompartment(XPCJSRuntime:Get()->GetJSContextStack()->Peek()))) So basically just pointer chasing. We do this several times for every wrap() call, for comparison.
Comment 24•10 years ago
|
||
Yes, and wrap() is slow.... I guess we're doing a bunch of it anyway here. :(
Assignee | ||
Comment 25•10 years ago
|
||
Green try push in comment 14. remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/6a0ebe4ddd01 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/2a530ceeac5d remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/b057716623f9 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/cac7844c804d remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/5360c2573b11 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/4503fdf32a31 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/4fc776ee6852
Comment 26•10 years ago
|
||
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/1e8c2e85575a for b2g emulator bustage a la https://tbpl.mozilla.org/php/getParsedLog.php?id=34717947&tree=Mozilla-Inbound
Assignee | ||
Comment 27•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=d607ce9c51e6
Assignee | ||
Comment 28•10 years ago
|
||
remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/ccf60cc8004b remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/b4c42334f112 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/feacaec8b463 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/4e21b5c857cb remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/95570aef1a27 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/c7c4abfa527d remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/032861ed6fcc
Comment 29•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ccf60cc8004b https://hg.mozilla.org/mozilla-central/rev/b4c42334f112 https://hg.mozilla.org/mozilla-central/rev/feacaec8b463 https://hg.mozilla.org/mozilla-central/rev/4e21b5c857cb https://hg.mozilla.org/mozilla-central/rev/95570aef1a27 https://hg.mozilla.org/mozilla-central/rev/c7c4abfa527d https://hg.mozilla.org/mozilla-central/rev/032861ed6fcc
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•