Garrett Smith wrote:
I don't understand the pushback against location proxying
security-proxied objects. LocationProxy does actually play well with
security-proxied objects.

That was not our experience in the recent past. I'll have to document the problems, assuming that I can reproduce them.

I wonder if it would make sense for the trusted adapter machinery to
simply set __parent__ on adapters if either the adapter provides ILocation
*or* the adapter doesn't already have a __parent__.  This would solve the
problem and avoid the proxy.


-- Garrett

Dominik Huber wrote:

Jim Fulton wrote:

Dominik Huber wrote:

A few months ago the following code block was removed in, and (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,

As a consequence each trusted adapter class should now implement

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

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

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.


- A regular schema does not extend ILocation therefore it is not
obvious to write an adapter implementing ILocation.


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

Dominik Huber

Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to