faassen at vet
Oct 30, 2001, 6:04 PM
Post #7 of 7
(1702 views)
Permalink
|
Karl Anderson wrote:
> Martijn Faassen <faassen [at] vet> writes:
>
> > The problem is that David Mertz' XML pickle strategy pickles object
> > attributes, but doesn't do much about methods. The equivalent would be
> > exposing to the DOM (as attributes or perhaps as sub element nodes or
> > a mixture) the attributes of some persistent Zope object.
> >
> > That's not very useful in the Zope content for a number of reasons:
> >
> > * security; the innards shouldn't be exposed like that generally.
> > Normally you get to this by using methods which do security checks,
> > etc.
>
> Well, I never thought that ZDOM would interact with the security
> mechanism in a DOMish way. A DOM method such as attributes() would
> return whatever the security context allowed, just like any other
> method called with a security context, but the restricting wouldn't
> have anything to do with how the DOM calls are invoked.
Right, I'm not sure I was claiming it would. What the DOM adapter
would have to do is make sure the user is actually allowed to use the
methods the adapter is calling to construct the DOM representation.
But here I was objecting to the idea to generate a DOM representation
automatically by looking at the object innards (i.e. private
attributes), instead of using an adapter approach.
An compromise approach later discussed in this thread would be
semi automatic way to translate Zope API to DOM representation. This would
make make adapter construction a lot easier.
> In other words, a Python call of a ZDOM method would be as
> unrestricted as any other Python access of the DB, while a
> hypothetical XPath access of ZDOM invoked via a web interface would
> only see what was allowed by that interface's security context.
Right, if you use unrestricted Python it should just return as much
as possible. The implementation would be using unrestricted
Python, however, wouldn't it? So we'd need to check there explicitly,
(or pass some security context along?) unless I'm missing something.
Is this automatic?
> But
> that security isn't expressed meaningfully by the DOM, it's expressed
> by the fact that these are still Zope objects - that is, a ZDOM object
> might have an ac_permissions DOM attribute, but security isn't handled
> by accessing that interface thru the DOM, and the custom adapter (like
> mentioned below) might not even expose it.
>
> IOW, security doesn't change. I never thought too hard about it,
> though, is this a naive?
Well, it's basically what I'd like to implement, but wouldn't the
ZDOM implementation be unrestricted Python, just like an external method
or any product method? I.e. if you can bypass the security by going through
ZDOM that'd be bad. You can't just restrict access to ZDOM methods with
security declarations to fix this, either. The ZDOM methods themselves
need to check for permission, right?
> > What needs to happen, and why I think a registry of adapters is unavoidable,
> > is that we expose what's accessible through object's APIs to the DOM somehow.
> > So, an objectValues() would turn into a list of childNodes. Properties
> > and other attributes can often become attribute nodes. Text contained by
> > some object can become a text node. The representation to the DOM should:
>
> Adapters are unavoidable because the DOM is document-centric.
> Otherwise the only way to look at the ZODB would be as one large
> document rooted at Zope.app().
Because you'd need to construct the entire XML representation of the entire
tree in one go otherwise? Yes, adapters are 'lazy', which is good, but
I was talking about the need for a *registry* of adapters instead of
having some form of super adapter that does the translation fully
automatically (or adding a super mixin to objects to do this DOM
representation).
Regards,
Martijn
|
