Jim Fulton wrote:
- 1
It might be a trap too, because developers must be aware of the pretty implicit differnces between trusted and unstrusted adapters.
We just need to make this explicit.
We already "implicitly" set __parent__ in the trusted adapter factory. I suggest we make this explicit. If you ask for a trusted adapter, then we'll set __parent__ on the adapter to the adapted object, adding a location proxy, if necessary.
How can I ask for trusted adapters explicitly inside a framework such as edit view?
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.
where unstrusted adapters require a dedicated permission the editview has still to proxy those adapters to procede correctly. Would it be possible to deprecate the unstrusted adapters or proxy them to?
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 I use the permission attribute registering multiadapters (views) all the time, what's the problem there? I'm not aware of any problems.
The zope.Public permission is within all our use cases no alternative.
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) ...
IMO all permission related stuff is possibly location sensitive stuff, therefore the 'real' criteria must be this permission issue and not the trusted/untrusted-issue.
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.
from zope.app.location import assertLocation
locatable_adapter = assertLocation( IAnyInterface(context)) doAnyLocationSensitiveProcedure(locatable_adapter)
Then we have to build location proxies most of the time. Is that not a performance issue?
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.
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: - Performance: Diffinitaly an overhead + Explicitness: Excplicit in relation to the location issue after adaption + Developer: Can forget about the location issue
Regards, Dominik
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
