Dominik Huber wrote:
Jim Fulton wrote:

...
How can I ask for trusted adapters explicitly inside a framework such as edit view?

You can't.

If we adapt a context to a certain schema (given by the schema attibute of the editform directive) we have no chance today to ask explicitly for a trusted adapter but rather we get either an untrusted or a trusted one. So if we don't like to end up in the status-quo-bug we have still to handle unlocatable untrusted adapters someway.

Whether something is trusted or not is an implementation decision of the adapter.

...

I would strongly discourage the use of untrusted adapters that
require a permission other than zope.Public.


Then we should not allow to set the permission attribute in the adapter directive ;)

But *sometimes*, it's necessary.

But I use the permission attribute registering multiadapters (views) all the time, what's the problem there? I'm not aware of any problems.

That's because the BrowserView base class provides ILocation and the view-lookup machinery sets __parent__. The high-level view directives use this base class.

The zope.Public permission is within all our use cases no alternative.

Not within all, but if an adapter *only* provides logic, then it's better IMO to rely on the underlying object protections.

In general, adapters are rarely accessed from untrustes code
and are rarely security proxied.  I would not want to location
proxy them in general.


Yup.
But my problem is the implicite behavior of the adapter interfaces. IMO we still end up in code like the following
...
adapter = IAnyInterface(context)
if not ILocation.providedBy(adapter):
locatable_adapter = LocationProxy(adapter)
locatable_adapter.__parent__ = context.__parent__
locatable_adapter.__name__ = context.__name__
else:
locatable_adapter = adapter
>
> doAnyLocationSensitiveProcedure(locatable_adapter)
> ...
>

In this example, the adapter won't be proxied unless either
the example code is untrusted, which I assume is not the case,
or the adapter is a trusted adapter.  If the adapter is trusted
and we arrange for all trusted adapters to be locations, then the
extra code should not be necessary.  (BTW, the __name__ assignment
above is pointless.)

IMO all permission related stuff is possibly location sensitive stuff,

In practice yes. This is because current security policies use location to look up grants.

therefore the 'real' criteria must be this permission issue and not the trusted/untrusted-issue.

Except that the two are linked. Trusted adapters provide a way to deal with adapter security. Most adapters should not be protected. The only adapters that should be protected are trusted adapters and adapters that access sensitive external resources. The vast majority of adapters don't fit into either of these categories.

IMO the optimum of explicitness would be reached using only a location helper function such as assertLocation(). We should resign our plans to modify the trusted adapter factory using location proxies if not ILocation is provided by the adapter, because those arrangements do not solve the problem really, as long as we have to differ adapters in relation to their location behavior.

Sorry, I can't make out this translation. :)

from zope.app.location import assertLocation

locatable_adapter = assertLocation( IAnyInterface(context))
doAnyLocationSensitiveProcedure(locatable_adapter)

That's fine. Of course, it isn't really adapter specific.


Yes, we don't want to do this most of the time.  It makes sense IMO,
to use them for trusted adapters, but I consider trusted adapters to
be a fairly specialized (and useful) tool.

That would be strengthen the location helper function, too.

So are you agreeing with the proposal to add location proxies in the adapter factory and not in the form machinery?


Summary: ---------- I try to collect + and -:

location helper function:
+ Performance: We don't have to build location proxies all the time
+ Explicitness: Excplicit in relation to the location issue after adaption
0 Developer: Have to be aware of the location issue

assert a location to all trusted adapters:
0 Performace: Ok because only the trusted adapters are affected
- Explicitness: Implicit in relation to the location issue after adaption
0 Developer: Have to be aware of the location issue

assert a location to all trusted adapters:

Did you mean "all adapters"?

Jim

--
Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
_______________________________________________
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