308
edits
Changes
→Implementation notes
= Implementation notes =
Implementing this proposal properly would probably involve the following steps:
# Decouple the concept of "subject principal" from the JS context stack. Have a separate principal stack.
# Push the current JS subject principal on this stack when calling out of JS into C++ (via XPConnect or any C++-implemented JS getter/setter/function).
# When posting an event to a thread event queue, save the current subject principal with the event (in the event queue code). When dispatching the event, push that principal on the stack. This ensures that the principal for an action is the same whether the action is taken sync or async. The other option is to make all event consumers do this manually, and that seems ''really'' suboptimal.
# Handle timers like events.
# Same for all other cross-thread communication.
# Necko channel callbacks (<code>onStartRequest</code>, <code>onDataAvailable</code>, <code>onStopRequest</code>) would require the necko channel to push its principal (either the owner, or the principal derived from the URI) before making callback. The other option is to have all <code>nsIRequestObserver</code> implementations do this themselves. The goal here is that when parsing a document the subject principal is that document's principal.
# Change the handling of chrome JS such that it does NOT affect the principal stack. Calling foo() from bar() from baz() should behave identically whether bar() is implemented in chrome JS or in C++ -- in both cases foo() should see the same subject principal as baz().
# Implement a way for both C++ and chrome JS to push a different principal (e.g. the system principal) when they are no longer doing work "on behalf" of someone.
# Audit our codebase to see where else we need to change the current principal.
Note that the principal stack would probably need to hold nsISupports given that we'd need necko and xpcom support for it. It should live in xpcom.
