[Zope3-dev] Form framework, adapters and pau

Jim Fulton jim at zope.com
Wed Apr 20 08:00:29 EDT 2005


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.

> So, during the registration of an trusted adapter  factory (<adapter...) 
> I can't do any prediction about the
> permission declaration of the possible adapter instances (<class ...). 
> Therefore we can't switch the
> adapter factories within the adapter directive processing..

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.


> All the same I implemented your sugestion. The following question appears:
> - How should we handle NullAdapters correctly?

What do you mean by NullAdapters?  Are you talking about factories that
return None?

Id so, then, obviously, you should not proxy None.

> 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.

> We should find a way to check the permission of the adapter instances 
> inside a single trusted adapter factory:
> 
> class IntelligentTrustedAdapterFactory(TrustedAdapterFactoryMixin):
> 
>    def _customize(self, adapter, context):
>        p = ProxyFactory(adapter)
>        checker = getChecker(p)
>        if checker is CheckerPublic:
>            return adapter
>        else:
>           return assertLocation(adapter, context)
 >
> Questions:
> - performance
> - in the key refernce example it would be an dedicated checker. how 
> could I guess if such an checker is Public?

This is just too much magic.  It has too many rules and
is too slow.

BTW, we are not just taking about trusted adapters.  We are talking about
*any* adapter for which a non-public permission is required.

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


More information about the Zope3-dev mailing list