On Jul 5, 2009, at 5:19 AM, Adam Barth wrote:
On Sat, Jul 4, 2009 at 9:13 PM, Maciej Stachowiak<m...@apple.com>
wrote:
If you have specific ideas about changes to the JS bindings we can
go over
them soon. The general idea of factoring out a separate class to
handle
security policy seems good. "Manager" is one of the things in class
names I
tend to be allergic to. Instead of "SecurityManager" I would
consider names
like "SameOriginPolicy" or "SameOriginAuditor" or something like that
(assuming the main security-related thing it does is enforce the
same-origin
policy).
The same-origin policy itself mostly handled by the SecurityOrigin
class in WebCore proper. The main purpose I plan for this new class
is to understand the mapping between the current state of the
JavaScript engine (the ExecState in JSC terms) and a security context
(be it a Frame, a Document, or a SecurityOrigin) and how to get useful
information from these objects (e.g., how to call
SecurityOrigin::canAccess, log the warning message, etc). Maybe
JSSecurityContext would be a better name?
That sounds like a pretty good name based on your description.
- Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
