Allow runtime's security callbacks to be overridden by a context

RESOLVED FIXED in mozilla1.9.1



JavaScript Engine
9 years ago
7 years ago


(Reporter: Ben Turner (not reading bugmail, use the needinfo flag!), Assigned: jorendorff)



Dependency tree / graph
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)

Created attachment 335066 [details] [diff] [review]
Move checkObjectAccess to JSContext, v1

checkObjectAccess is currently set on the JSRuntime and so my background threads are using caps (which is not threadsafe). I have my own sandbox so I'd like to make the checkObjectAccess settable from the context as I control the lifetime of the contexts I'm using. Patch attached.
Attachment #335066 - Flags: review?(brendan)
I'll file a followup to fix xpconnect, dom, and caps.
Blocks: 451731
(In reply to comment #1)
> I'll file a followup to fix xpconnect, dom, and caps.

Bug 451731.
Blocks: 450449
Comment on attachment 335066 [details] [diff] [review]
Move checkObjectAccess to JSContext, v1

Great, thanks. Who will do the dev-doc-needed deed? Do we even have API doc on this callback?

Attachment #335066 - Flags: review?(brendan) → review+
Created attachment 336732 [details] [diff] [review]
Make callbacks overridable on the context, v1

Talking about this with jst and brendan we decided to change directions here. We're going to leave the callbacks on the runtime as defaults that can be overridden by individual contexts. Also they've moved into their own callback struct.
Attachment #335066 - Attachment is obsolete: true
Attachment #336732 - Flags: review?(brendan)
Summary: Move checkObjectAccess from the JSRuntime to the JSContext → Allow runtime's security callbacks to be overridden by a context
Duplicate of this bug: 453373
Blocks: 453380
Attachment #336732 - Flags: review?(brendan) → review+
Comment on attachment 336732 [details] [diff] [review]
Make callbacks overridable on the context, v1

>+extern JS_PUBLIC_API(JSSecurityCallbacks *)
>+JS_SetSecurityCallbacksRT(JSRuntime *rt, JSSecurityCallbacks *callbacks);
>+extern JS_PUBLIC_API(JSSecurityCallbacks *)
>+JS_GetSecurityCallbacksRT(JSRuntime *rt);
>+extern JS_PUBLIC_API(JSSecurityCallbacks *)
>+JS_SetSecurityCallbacks(JSContext *cx, JSSecurityCallbacks *callbacks);

These are misnamed -- elsewhere, the RT suffix just means a change of parameters, not a change of semantics. Suggest JS_SetRuntimeSecurityCallbacks, JS_GetRuntimeSecurityCallbacks, and JS_SetContextSecurityCallbacks.

>+extern JS_PUBLIC_API(JSSecurityCallbacks *)
>+JS_GetSecurityCallbacks(JSContext *cx);

This one is different, and well-named. I can't think of a longer name that conveys how it falls back on the runtime's callbacks if the context has none set.

Looks great otherwise, r=me with name fixage.

Pushed changeset 7da53f4cd712 to mozilla-central with brendan's comments addressed.
Last Resolved: 9 years ago
Resolution: --- → FIXED
We're going to need some documentation updated for this change.

JS_SetCheckObjectAccessCallback, JS_SetPrincipalsTranscoder, and JS_SetObjectPrincipalsFinder have been superseded by JS_SetRuntimeSecurityCallbacks and JS_SetContextSecurityCallbacks.

Consumers that wish to use one of the callback functions should call JS_GetSecurityCallbacks which will favor the callbacks set on the context over those on the runtime.
Keywords: dev-doc-needed


9 years ago
Flags: in-testsuite-
Flags: in-litmus-
Is someone going to write this up, or do I need to beg for details on these and do it myself? :)

Comment 10

9 years ago
I added a bullet in the 1.8 release notes mentioning that the old APIs are deprecated and will be removed in 1.8.1.

I did some preliminary dev-doc stuff too but it's not done.
jorend - any chance you can find time to finish these up?  I suspect it's much more efficient for you to do it than for me; if you can't, I'll take a whack at it though.
Assigning to jorend for doc purposes.
Assignee: bent.mozilla → jorendorff
In part, the docs would be here:
You need to log in before you can comment on or make changes to this bug.