Closed Bug 451729 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.1

People

(Reporter: bent.mozilla, Assigned: jorendorff)

References

Details

(Keywords: dev-doc-needed)

Attachments

(1 file, 1 obsolete file)

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.
(In reply to comment #1)
> I'll file a followup to fix xpconnect, dom, and caps.

Bug 451731.
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?

/be
Attachment #335066 - Flags: review?(brendan) → review+
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
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.

/be
Pushed changeset 7da53f4cd712 to mozilla-central with brendan's comments addressed.
Status: ASSIGNED → RESOLVED
Closed: 12 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.
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? :)
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
You need to log in before you can comment on or make changes to this bug.