[Zope3-dev] Form framework, adapters and pau

[Jim Fulton]

Dominik Huber wrote:
> Jim Fulton wrote:
> 
>> Dominik Huber wrote:
>>
>>> Excuse me late response I was busy that weekend...
>>>
>>> Jim Fulton wrote:
>>>
>>>>> I fixed that issue within the branch 
>>>>> 'Zope3/branches/dominik-locatableadapters'
>>>>> Jim, could you take a look at that please. Thank you very much in 
>>>>> advance!
>>>>
>>>>
>>>>
>>>>
>>>>
>>> [...]
>>>
>>>>
>>>> We should *only* add the location if the adapter requires a 
>>>> permission other
>>>> than zope public.  Key rereferences don't require a permission and 
>>>> should not
>>>> be location proxied. Doing so makes them unpicklable.
>>>>
>>>> We're going to need to fix the trusted adapter factory to do this 
>>>> correctly.
>>>> I suggest we create a new kind of trusted adapter factory, perhaps
>>>> "LocatingTrustedAdapter" factory that adds the location. This should
>>>> only be used when the adapter directive specified a permission other
>>>> than zope.Public. Otherwise, the original trusted adapter factory 
>>>> should
>>>> be used.
>>>
>>>
>>>
>>>
>>> May be I do not understand the problem correctly:
>>>
>>> IMO the permission declaration within the adapter directive has 
>>> nothing to do
>>> with the permission declaration wihtin the class directive that mus 
>>> be used if
>>> trusted adapters are invoked.
>>
>>
>> >
>>
>>>
>>> Example KeyReference Adapter:
>>>
>>>  <adapter
>>>      for="persistent.interfaces.IPersistent"
>>>      provides=".interfaces.IKeyReference"
>>>      factory=".persistent.KeyReferenceToPersistent"
>>>      trusted="y"
>>>      />
>>>
>>>  <class class=".persistent.KeyReferenceToPersistent">
>>>    <require permission="zope.Public" 
>>> interface=".interfaces.IKeyReference" />
>>>  </class>
>>
>>
>>
>> That's odd.  I didn't notice the class directive.  I don't know why the
>> class directive is being used here. This is one of those rare cases where
>> we have to make the security declaration on the adapter class. (In this
>> case, it's because the adapters are pickled, which is also unusual.)
>>
>> It is not generally the case that you need to use separate security
>> declarations with trusted adapters.
> 
> 
> I declare those additional class directive all the time if I'm using 
> trusted adapters.
> IMO this kind of registration is the common pattern
> 
> For example stephan richter uses this pattern within the wiki:
> 
>  <adapter
>      factory=".wikipage.WikiPageHierarchyAdapter"
>      provides=".interfaces.IWikiPageHierarchy"
>      for=".interfaces.IWikiPage"
>      trusted="true" />
> 
>  <class class=".wikipage.WikiPageHierarchyAdapter">
>    <require
>        permission="zwiki.ViewWikiPage"
>        attributes="parents path findChildren"
>        />
>    <require
>        permission="zwiki.ReparentWikiPage"
>        attributes="reparent"
>        set_attributes="parents"
>        />
>  </class>

This isn't a pattern I've used.  I think that there are
lots of other, and perhaps better ways to do things.

>>> permission declaration of the possible adapter instances (<class 
>>> ...). Therefore we can't switch the
>>> adapter factories within the adapter directive processing..
>>
>>
>> So, during the registration of an trusted adapter  factory 
>> (<adapter...) I can't do any prediction about the
>>
>> No, you can't do so implicitly.  You can know about the permission
>> used if a non-public permission was supplied.  If a non-public permission
>> is supplied, then it is reasonable to add the location. Otherwise, you 
>> should
>> not try to guess.
> 
> 
> But the permission declaration within the adapter directive defines the 
> permission that is nessecary to invoke the adapter factory.
 >
 > It's implict to asume that the  instance by a certain factory desires
 > the same permissions like the invocationg of the factory.
 >
 > It's implict to asume that the  instance by a certain factory desires
 > the same permissions like the invocationg of the factory.

Aaaaah.

You missunderstand.  The permission is not the permission to
to create the adapter. It's the permission necessary to use
the provided interface on the adapter.

>>> - How should we handle NullAdapters correctly?
>>
>>
>> All the same I implemented your sugestion. The following question 
>> appears:
>>
>> What do you mean by NullAdapters?  Are you talking about factories that
>> return None?
>>
>> Id so, then, obviously, you should not proxy None.
> 
> 
> No, 'NullAdapter' are parameterless factories, for example x = IX()

OK, so these cannot be locations.

>>> IMO this solution is pretty implicit and I do not like it at all.
>>
>>
>>
>> What solution?  If you are talking about my suggestion to
>> add a location to any adapter for whoch a non-public permission
>> is specified, then I consider this far less impleicit than what you
>> had before.  It doesn't guess. If it knows a permission is required,
>> it adds a location.
>>
> Yes, the current solution in the branch.

OK, I'll take a look at that.

...

>> BTW, we are not just taking about trusted adapters.  We are talking about
>> *any* adapter for which a non-public permission is required.
> 
> 
> Yes, thats clear.
> We have two cases:
> 1. untrusted
> 2. trusted
 >
> 1. if we register an untrusted adapter using the adapter directive we 
> can make an correlation between adapter factory permission and
> adapter instance: if I have no permission to invoke the factory, I 
> should not be able to use its instances.

Again, you are missunderstanding what the permission in the adapter
directive is about.

> 2. if we register a trusted adapter this correlation breaks because the 
> adapter instance itself might have highly differented security-permission
> (compare <class...)

In a complex situation like this, I suggest it's better to have people

make their adapters locations in Python.

> So 1 is easy to handle in the adapter directive, but 2 not. The 
> suggestion above tries to respect your requirments, but also allow to use.
> the registration pattern <adapter... and <class.. which is failry common 
> and explicit.
> 
> The current solution in the branch is not able to handle 2. correctly.
> Stephan's zwiki example:
> - The adapter directive has no permission (which is ok, because he 
> doesn't need to protect the invocation of the adapter factory itself).
> - In that case the locating trusted adapter factory is not invoked 
> within the registration.
> - Therefore the adapter instance will not have any location.
> - Therefore we can't invoke the local authentication.
> 
> My suggestion:
> IMO the intid and keyrefernce stuff is an exceptional case. Nobody else 
> using the zope framework tries to memorize adapters persistently.

The problem is that we were being too intrusive.

Most adapters are never security proxied. We shouldn't implicitly
add location proxies. We should only add them if we know we need them.

> Everyone is aware that adapters regularly are very transient.
> If somebody needs a pickable adapter he should be aware that those 
> adapter must provide ILocation and must be trusted.

That's very intrusive and unacceptable.  KeyReferences have no reason
whatsoever to be locations. They are publically available.  The only
reason they "needed" to be locations was because of your implicit
addtion of the location proxy.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org