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




_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Reply via email to