[Zope3-dev] Form framework, adapters and pau

[Dominik Huber]

Jim Fulton wrote:


> Dominik Huber wrote:
>
>> A few months ago the following code block was removed in editview.py, 
>> editwizard.py and schemadisplay.py (revision 29418):
>>
>>    def _setUpWidgets(self):
>>        adapted = self.schema(self.context)
>>        if adapted is not self.context:
>>            if not ILocation.providedBy(adapted):
>>                adapted = LocationProxy(adapted)
>>            adapted.__parent__ = self.context
>>        self.adapted = adapted
>>        setUpEditWidgets(self, self.schema, source=self.adapted,
>>                         names=self.fieldNames)
>>
>> As a consequence each trusted adapter class should now implement 
>> ILocation
>
>
> One could, as an alternative, use an non-trusted adapter
> that is public and rely on the underlying object protection.

We can only use trusted adapters for our use case.

>
> > that the TrustedAdapterFactory can set the location of adapter
>
>> instances correctly. Otherwise, only the global authentication is 
>> involved and the edit view fails if any local principal tries to edit 
>> a certain field (security.canWrite(source, name) in 
>> zope.app.form.utility line 207).
>>
>> I would like to revert those changes. IMO a framework like the form 
>> framework knows the context (location) and adapts that context to a 
>> certain schema. If the following procedures depends on location 
>> information, the framework itself should pass such informations in a 
>> smart way. It's an unnecessary 
>> <se?lp=ende&p=/Mn4k.&search=unnecessary> expense 
>> <se?lp=ende&p=/Mn4k.&search=expense> to force all schema adapters to 
>> implement ILocation:
>>
>> - The solution using the location proxy seems fairly famillar
>>  compared with the container framework and containment that does not
>>  provide ILocation.
>
>
> Except that the object being location proxied is already security
> proxied.  Location proxies were not designed to proxy security-proxied
> objects.

Theory:
I cannot assess this location-proxied securtiy proxy issue. Therefor I 
have a question about the order of containment proxies:
1. contained proxy > security proxy > component
2. security proxy > contained proxy > component
So far I thought a component is created and proxied by their factory, 
afterwards it is contained proxied by the container if it does not 
provide ILocation. Therefor my statemets bases of 1.

So for me it is not very obvious what the difference should be between 
location proxied containement and location proxied trusted adapters:
location proxy > security proxy > trusted adapter

Practise:
The form framework does not work using trusted adapters which do not 
provide ILocation in combination with the local authentication 
information. This raises an Unauthorized exception if a local principal 
with enough privileges tries to access the edit view. (Reason: Because 
the unlocatable adapter invoke the global authentication only).

We have three oportunities:
a) status quo
b) location proxy or simalar derivates
c) extend security.canWrite(obj, name, context=None)
d) ...

History:
Roger removed the location proxy code because at that time the security 
information get lost using location proxies (Reason multiple security 
proxies: security proxy > location proxy > security proxy > trusted 
adapter). Afterward Garret fixed the proxy method of the Checker class. 
Since that time proxied object will be only proxied if their were not 
already proxied before (location proxy > security proxy > trusted adapter)

>
>> - An adapter that implements more than one interface cannot be 
>> registered
>>  with the implicit adapts and implements informations.
>
>
> True.
>
>> - A regular schema does not extend ILocation therefore it is not 
>> obvious to
>>  write an adapter implementing ILocation.
>
>
> True.
>
If you answers the last two reasons with True then follows IMO a) is a bug.

So we have to choose an other implementation alternative
b),  c) or d) would be ok for me.

>> Any objections?
>
>
> Yes. :)
>
> Why not simply use an untrusted public adapter?

Use case:
We have within the site 's' an extendable containerish component 'f' 
(Class Fasade) that should fasade its containment . Inside 'f' we can 
put any component for example component 'any' (Class Any) providing 
'IAny'.The IWriteContainer declaration of 's' requires the permission 
'zope.ManageContent'. The IWriteContainer declaration of 'any' requires 
a dedicated permission for example 'zope.ManageInside'.

Now we should provide an edit-view for 'f' that invokes the contained 
component 'any'. The edit-view should be accessable for local principal 
of s which have the 'zope.ManageContent' permission.

Our design goal tries to satify the following two targets:
- demeter's law (No direct access to 'any').
- different permission between inside and outside 'f'

So we decided to access 'any' on the location of 'f' using an 
AnyForFasade adapter.
IMO this adapter must be trusted to hide inside permission of 'any'.

Regards,
Dominik Huber