This sounds like a good approach. Historically, we've tried to keep as many of the security checks in the bindings themselves because they might not be applicable for bindings to other languages, such as Objective C. In some cases, like javascript URLs, the API surface in the bindings was too huge, so we moved the security check into WebCore, where a nice choke-pointed existed.
I definitely support making the bindings layer as thin as possible. In my ideal world, everything in the bindings would be auto-generated from the IDL, making it harder to introduce correctness or security bugs in the bindings layer (which has a very large "surface area" exposed to web content). I'd be more than happy to review any patches in this area. Adam On Tue, Dec 7, 2010 at 11:25 AM, Darin Adler <[email protected]> wrote: > Hi folks. > > I recently noticed that far too much of the logic for the DOM window object > is in the JavaScript bindings rather than in the DOM implementation of the > window object itself. I also see efforts to make a “generic” binding that is > currently used mostly for V8 only but seems intended for later use by JSC. > > I think we’re going about this the wrong way. The general rule for the DOM is > to do the work in the DOM classes rather than in the binding. The job of the > binding is to extract the arguments and call through to the DOM. This is how > we should be doing it. > > Let me give an example. When setting the location attribute of the DOM > window, the binding should extract the active frame and first frame, convert > the value of the attribute to a string, and then call through to the > DOMWindow object. The security logic should be in the DOMWindow.h/cpp file, > not in the binding. > > I know this is a departure from what was in JSDOMWindowCustom.cpp; but that > historic code is not a good template to base future code on. We should desist > in making a cross-JavaScript-engine binding layer for code that doesn’t > belong in the binding layer at all. > > I’m working on a patch for setLocation and then I’ll move on to open and > showModalDialog. > > Once we have done enough of this work, we should be able to remove a lot of > unneeded code from files like BindingSecurity.h, BindingSecurityBase.h, > BindingSecurityBase.cpp, BindingLocation.h, BindingFrame.h, > BindingDOMWindow.h, GenericBinding.h, JSDOMWindowBase.h, and > JSDOMWindowBase.cpp. > > We really don’t want to spread security responsibilities into the bindings. > What the bindings need to do is communicate the scripting context when > calling in the DOM. The DOM can implement security rules and such in a way > that’s independent of the bindings. > > Let me know what you think. > > -- Darin > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
