Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: So at the moment I do not see any another possibility to set those permissions than using an additional class.. directive. All 'bugs' related to this issue (that I'm aware of) including the zwiki-bug that was reported uses the above pattern and breaks. The reason for my branch was to solve this kind problem :) But your original fix caused other problems. Only if somebody is memorizing (and pickle) adapters. Please be honest, that's not the most ordinary application. (at least there were definitely more application using the above pattern. ;) This isn't about the the specific pickling problem. It's about the unexpected problems from implicitly proxying something. Proxies are a technology that should be used only when necessary. This whole discussion is about providing the convenience of not having to subclass Location in an adapter class when an adapter is going to be security proxied. While I think this convenience has value, the value does not justify always adding the location proxy. Yes and No. It's convience, but it's also fact that security lookups do need a location (unless zope.Public) to invoke local security settings correctly. So, we have two cases: 1. the developer is *fully aware* of the security and adapter machinery. 2. the developer is *not aware* of the security and adapter machinery. Today dev 2 is going to struggle and he will have a hard time to find the bug. The current branch prevents that dev 2 struggles. Dev 1 might be disturbed by an implicit location proxy, but he is able to handle the problem deriving his adapter class from ILocation. ... 2. the resulting adapter requires the permission defined by class.. adapter factory=.wikipage.MailSubscriptions provides=.interfaces.IMailSubscriptions for=.interfaces.IWiki *permission=any.Permission* trusted=true / class class=.wikipage.MailSubscriptions require permission=zwiki.EditWikiPage attributes=getSubscriptions / require permission=zwiki.EditWikiPage attributes=addSubscriptions removeSubscriptions / /class IMO case 2. happens (experimental verification only, I do not understand all magics within _protectedFactory). The status-quo is pretty implicit too. I looking forward to explain such stuff to newbies ;) In this case, the designer needs to do one of: - Make their adapter class a location - Factor their adapter into separate adapters that each do one thing and need a single permission. I just thought of another alternative in the case of single adapters. The adapter directive lets you name multiple factories in the factory attribute. You could list the location proxy constructor as a factory in the ZCML: adapter ... factory=.MyOriginalFactory zope.app.location.LocationProxy Here, we are *explicitly* saying that we want to combine an aplication factory with a location proxy. This works for the example above. Yup. -1 That's might be *to much explicitness* for dev 1 and complecates the adapter directive too. We missed us. Question: What should the precedence be if I use the sample zwiki registration (modified example above)? At the moment (trunk) the permission attribute of the adapter... is ignored and the permission-set of the class... is invoked (experimental verification only). I couldn't tell you what the precedence should be because I didn't anticipate that someone would do both. Here's what I want: The adapter directive grows a new feature. If the adapter directive has a permission directive with a permission other than zope.Public and the adapter adapts one or more objects, then we provide a factory that: - Adds a location proxy if it doesn't provide ILocation, and - Sets the __parent__ if the existing value is not None Dis you implement this? I tried to implement your solution [Revision 30053], but then I noticed the following problems: 1. no permission (None) and zope.Public within a trusted adapter registration provokes different behavior (example below KeyReferenceToPersistent) OK, sounds like a bug. 2. the zwiki bug and my related implementations bugs still exists, because regularly folks that registering trusted adapters using adapter... and class...do not set any permission within adapter.., but only within class (That kind of permission declaration causes the invocation of the regular-trusted-adapter-factory.) Therefore I reverted 'your' solution back to the first implementation [Revision 30059, 30060]. That's not acceptable I assumed that it will be less evil to do without two different trusted adapters factories (regular (zope.Public and None) and the locating one (other permission)). + we can fix the zwiki bug and related implementations bugs easily + we can omit the unclear permission-precedence if the adapter... class... pattern is used for trusted adapters o the untrusted adapters with no location get only location-proxied if
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: Dominik Huber wrote: Jim Fulton wrote: ... Here are 2 other alternatives to consider: 1. Add a locate option to the adapter directive, which defaults to false. If true (locate=1), then a location proxy is always added to the adapter. Yup. -1 That's might be *to much explicitness* for dev I really don't think so. 1 and complecates the adapter directive too. Actually, I think it simplifies it a little. It separates trusted-ness from location-ness. 2. Option 1 but default to true if a non-public permission is specified. These alternatives are explicit and hande the case where permissions are declared in a separate directive. In both sugestions the problem is not solved, that the public permission declaration within the adapter directive cannot be adapted to all trusted adapters, because the 'valid' security-declartations might be registered within an addional class... I think you are mistaken. If you declare permissions in a class directive, you'd use a locate attribute in the adapter directive, as in: adapter factory=.myFactory trusted=1 locate=1 / class class=.myFactory require permission=X interface=IX / ... /class In this case you'd get the location even though the adapter directive doesn't specify a permission. Ok, I'm mistaken. That would be also fine with me. The only thing we have to do additionaly is to look for potential bugs like the zwiki example. Which alternativ do you prefer? I have time on wednesday to implement your selection within the branch. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: Dominik Huber wrote: Excuse me late response I was busy that weekend... Jim Fulton wrote: I fixed that issue within the branch 'Zope3/branches/dominik-locatableadapters' Jim, could you take a look at that please. Thank you very much in advance! [...] We should *only* add the location if the adapter requires a permission other than zope public. Key rereferences don't require a permission and should not be location proxied. Doing so makes them unpicklable. We're going to need to fix the trusted adapter factory to do this correctly. I suggest we create a new kind of trusted adapter factory, perhaps LocatingTrustedAdapter factory that adds the location. This should only be used when the adapter directive specified a permission other than zope.Public. Otherwise, the original trusted adapter factory should be used. May be I do not understand the problem correctly: IMO the permission declaration within the adapter directive has nothing to do with the permission declaration wihtin the class directive that mus be used if trusted adapters are invoked. Example KeyReference Adapter: adapter for=persistent.interfaces.IPersistent provides=.interfaces.IKeyReference factory=.persistent.KeyReferenceToPersistent trusted=y / class class=.persistent.KeyReferenceToPersistent require permission=zope.Public interface=.interfaces.IKeyReference / /class That's odd. I didn't notice the class directive. I don't know why the class directive is being used here. This is one of those rare cases where we have to make the security declaration on the adapter class. (In this case, it's because the adapters are pickled, which is also unusual.) It is not generally the case that you need to use separate security declarations with trusted adapters. I declare those additional class directive all the time if I'm using trusted adapters. IMO this kind of registration is the common pattern For example stephan richter uses this pattern within the wiki: adapter factory=.wikipage.WikiPageHierarchyAdapter provides=.interfaces.IWikiPageHierarchy for=.interfaces.IWikiPage trusted=true / class class=.wikipage.WikiPageHierarchyAdapter require permission=zwiki.ViewWikiPage attributes=parents path findChildren / require permission=zwiki.ReparentWikiPage attributes=reparent set_attributes=parents / /class permission declaration of the possible adapter instances (class ...). Therefore we can't switch the adapter factories within the adapter directive processing.. So, during the registration of an trusted adapter factory (adapter...) I can't do any prediction about the No, you can't do so implicitly. You can know about the permission used if a non-public permission was supplied. If a non-public permission is supplied, then it is reasonable to add the location. Otherwise, you should not try to guess. But the permission declaration within the adapter directive defines the permission that is nessecary to invoke the adapter factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. - How should we handle NullAdapters correctly? All the same I implemented your sugestion. The following question appears: What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. No, 'NullAdapter' are parameterless factories, for example x = IX() IMO this solution is pretty implicit and I do not like it at all. What solution? If you are talking about my suggestion to add a location to any adapter for whoch a non-public permission is specified, then I consider this far less impleicit than what you had before. It doesn't guess. If it knows a permission is required, it adds a location. Yes, the current solution in the branch. We should find a way to check the permission of the adapter instances inside a single trusted adapter factory: class IntelligentTrustedAdapterFactory(TrustedAdapterFactoryMixin): def _customize(self, adapter, context): p = ProxyFactory(adapter) checker = getChecker(p) if checker is CheckerPublic: return adapter else: return assertLocation(adapter, context) Questions: - performance - in the key refernce example it would be an dedicated checker. how could I guess if such an checker is Public? This is just too much magic. It has too many rules and is too slow. BTW, we are not just taking about trusted adapters. We are talking about *any* adapter for which a non-public permission is required. Yes, thats clear. We have two cases: 1. untrusted 2. trusted 1. if we register an untrusted adapter using the adapter directive we can make an correlation between adapter factory permission and adapter instance: if I have no permission to invoke the factory, I should not be able to use its instances. 2. if we
Re: [Zope3-dev] Form framework, adapters and pau
Dominik Huber wrote: Jim Fulton wrote: Dominik Huber wrote: Excuse me late response I was busy that weekend... Jim Fulton wrote: I fixed that issue within the branch 'Zope3/branches/dominik-locatableadapters' Jim, could you take a look at that please. Thank you very much in advance! [...] We should *only* add the location if the adapter requires a permission other than zope public. Key rereferences don't require a permission and should not be location proxied. Doing so makes them unpicklable. We're going to need to fix the trusted adapter factory to do this correctly. I suggest we create a new kind of trusted adapter factory, perhaps LocatingTrustedAdapter factory that adds the location. This should only be used when the adapter directive specified a permission other than zope.Public. Otherwise, the original trusted adapter factory should be used. May be I do not understand the problem correctly: IMO the permission declaration within the adapter directive has nothing to do with the permission declaration wihtin the class directive that mus be used if trusted adapters are invoked. Example KeyReference Adapter: adapter for=persistent.interfaces.IPersistent provides=.interfaces.IKeyReference factory=.persistent.KeyReferenceToPersistent trusted=y / class class=.persistent.KeyReferenceToPersistent require permission=zope.Public interface=.interfaces.IKeyReference / /class That's odd. I didn't notice the class directive. I don't know why the class directive is being used here. This is one of those rare cases where we have to make the security declaration on the adapter class. (In this case, it's because the adapters are pickled, which is also unusual.) It is not generally the case that you need to use separate security declarations with trusted adapters. I declare those additional class directive all the time if I'm using trusted adapters. IMO this kind of registration is the common pattern For example stephan richter uses this pattern within the wiki: adapter factory=.wikipage.WikiPageHierarchyAdapter provides=.interfaces.IWikiPageHierarchy for=.interfaces.IWikiPage trusted=true / class class=.wikipage.WikiPageHierarchyAdapter require permission=zwiki.ViewWikiPage attributes=parents path findChildren / require permission=zwiki.ReparentWikiPage attributes=reparent set_attributes=parents / /class This isn't a pattern I've used. I think that there are lots of other, and perhaps better ways to do things. permission declaration of the possible adapter instances (class ...). Therefore we can't switch the adapter factories within the adapter directive processing.. So, during the registration of an trusted adapter factory (adapter...) I can't do any prediction about the No, you can't do so implicitly. You can know about the permission used if a non-public permission was supplied. If a non-public permission is supplied, then it is reasonable to add the location. Otherwise, you should not try to guess. But the permission declaration within the adapter directive defines the permission that is nessecary to invoke the adapter factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. Ah. You missunderstand. The permission is not the permission to to create the adapter. It's the permission necessary to use the provided interface on the adapter. - How should we handle NullAdapters correctly? All the same I implemented your sugestion. The following question appears: What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. No, 'NullAdapter' are parameterless factories, for example x = IX() OK, so these cannot be locations. IMO this solution is pretty implicit and I do not like it at all. What solution? If you are talking about my suggestion to add a location to any adapter for whoch a non-public permission is specified, then I consider this far less impleicit than what you had before. It doesn't guess. If it knows a permission is required, it adds a location. Yes, the current solution in the branch. OK, I'll take a look at that. ... BTW, we are not just taking about trusted adapters. We are talking about *any* adapter for which a non-public permission is required. Yes, thats clear. We have two cases: 1. untrusted 2. trusted 1. if we register an untrusted adapter using the adapter directive we can make an correlation between adapter factory permission and adapter instance: if I have no permission to invoke the factory, I should not be able to use its instances. Again, you are missunderstanding what the permission in the adapter directive is about. 2. if we register a trusted adapter
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: It is not generally the case that you need to use separate security declarations with trusted adapters. I declare those additional class directive all the time if I'm using trusted adapters. IMO this kind of registration is the common pattern For example stephan richter uses this pattern within the wiki: adapter factory=.wikipage.WikiPageHierarchyAdapter provides=.interfaces.IWikiPageHierarchy for=.interfaces.IWikiPage trusted=true / class class=.wikipage.WikiPageHierarchyAdapter require permission=zwiki.ViewWikiPage attributes=parents path findChildren / require permission=zwiki.ReparentWikiPage attributes=reparent set_attributes=parents / /class This isn't a pattern I've used. I think that there are lots of other, and perhaps better ways to do things. We have the use case that we adapt a lot of additional functionalities to a pretty stupid content. Each additional functionality has differentiated permission-sets comparable to regular content objects. For example different permissions for reading and setting attributes of the provided interface. So at the moment I do not see any another possibility to set those permissions than using an additional class.. directive. All 'bugs' related to this issue (that I'm aware of) including the zwiki-bug that was reported uses the above pattern and breaks. The reason for my branch was to solve this kind problem :) But the permission declaration within the adapter directive defines the permission that is nessecary to invoke the adapter factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. Ah. You missunderstand. The permission is not the permission to to create the adapter. It's the permission necessary to use the provided interface on the adapter. Ok, missleading naming _protectedFactory within the adapter handler ;) But what happens in the following case? 1. the resulting adapter requires any.Permission 2. the resulting adapter requires the permission defined by class.. adapter factory=.wikipage.MailSubscriptions provides=.interfaces.IMailSubscriptions for=.interfaces.IWiki *permission=any.Permission* trusted=true / class class=.wikipage.MailSubscriptions require permission=zwiki.EditWikiPage attributes=getSubscriptions / require permission=zwiki.EditWikiPage attributes=addSubscriptions removeSubscriptions / /class IMO case 2. happens (experimental verification only, I do not understand all magics within _protectedFactory). The status-quo is pretty implicit too. I looking forward to explain such stuff to newbies ;) - How should we handle NullAdapters correctly? All the same I implemented your sugestion. The following question appears: What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. No, 'NullAdapter' are parameterless factories, for example x = IX() OK, so these cannot be locations. Yup, that my interpretation too. So those null adapters are global object with or without dedicated permission that can't be invoke by any local principal. What's the use cases for such object? IMO this solution is pretty implicit and I do not like it at all. What solution? If you are talking about my suggestion to add a location to any adapter for whoch a non-public permission is specified, then I consider this far less impleicit than what you had before. It doesn't guess. If it knows a permission is required, it adds a location. Yes, the current solution in the branch. OK, I'll take a look at that. Excuse me, but under those circumstances I have to retract my solution. IMO it will be not that what you are looking for... :( 2. if we register a trusted adapter this correlation breaks because the adapter instance itself might have highly differented security-permission (compare class...) In a complex situation like this, I suggest it's better to have people make their adapters locations in Python. It might more complex than a single permission, but its every day life. I only try to simplify independently if its complex or not :) So 1 is easy to handle in the adapter directive, but 2 not. The suggestion above tries to respect your requirments, but also allow to use. the registration pattern adapter... and class.. which is failry common and explicit. The current solution in the branch is not able to handle 2. correctly. Stephan's zwiki example: - The adapter directive has no permission (which is ok, because he doesn't need to protect the invocation of the adapter factory itself). - In that case the locating trusted adapter factory is not invoked within the registration. -
Re: [Zope3-dev] Form framework, adapters and pau
addendum... I tried to implement your solution [Revision 30053], but then I noticed the following problems: 1. no permission (None) and zope.Public within a trusted adapter registration provokes different behavior (example below KeyReferenceToPersistent) 2. the zwiki bug and my related implementations bugs still exists, because regularly folks that registering trusted adapters using adapter... and class...do not set any permission within adapter.., but only within class (That kind of permission declaration causes the invocation of the regular-trusted-adapter-factory.) Therefore I reverted 'your' solution back to the first implementation [Revision 30059, 30060]. I assumed that it will be less evil to do without two different trusted adapters factories (regular (zope.Public and None) and the locating one (other permission)). + we can fix the zwiki bug and related implementations bugs easily + we can omit the unclear permission-precedence if the adapter... class... pattern is used for trusted adapters o the untrusted adapters with no location get only location-proxied if permission is not None or zope.Public - we have to derive the KeyReferenceToPersistent adapter from Location to omit the pickle error Just now I added some optimization [30067]: Trusted adapters get regularly only protected if the adapted object is protected. Therefore we can omit the location proxy in cases where the trusted adapters get not protected. I wrote an other adapter factory (PartiallyLocatingTrustedAdapterFactory) which is only using location proxies if the adapter is protected and does not provide ILocation. If ILocation is provided the parent is still set if None. And this that solves the KeyRefernceToPersistent problem too. [revison 30068] Within the current branch there are the three adapter factories: - PartiallyLocatingTrustedAdapterFactory - LocatingTrustedAdapterFactory - TrustedAdapterFactory You can easily switch them within adapter() directive handler and look for the optimum. After all I would prefer the current solution. But I know the decision is up to you. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Wiki permissions and PAU [Zope3-dev] Form framework, adapters and pau
Paolo Invernizzi wrote: I've a problem with the wiki that I can't resolve... Zope3 trunk current. I've added a PAU to http://eye:8080/++etc++site/default/@@contents.html with a PrincipalFolder and some principals. I've activated the No Challenge if Authenticated and the Zope Realm Basic-Auth I've also granted some principals in http://eye:8080/@@grant.html some principal of the folder with the Site Manager role. While everything is working pretty well, the principal can login, administer the site etc,etc I've a problem... I added a Wiki. While the principal can access single pages, the search in http://eye:8080/the_wiki/@@search.html, see the contents in http://eye:8080/the_wiki/@@contents.html, if cannot access the Table of contents http://eye:8080/the_wiki/@@toc.html (You are not authorized). That's an artefact of the problem we dicussed currently in [Zope3-dev] Form framework, adapters and pau thread. Only the global authentication is invoked, because the trusted WikiPageHierarchyAdapter does not implement ILocation. Therefore your user does not 'exists' during the authentication and that is leading to this failure. Temporary workaround: zwiki\wikipage.py line 73, derive WikiPageHierarchyAdapter from Location from zope.app.location import Location class WikiPageHierarchyAdapter(Location): ... We' ve planed to fix that problem correctly: http://mail.zope.org/pipermail/zope3-dev/2005-April/014140.html Regards, Dominik Huber ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
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-1714http://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
Re: [Zope3-dev] Form framework, adapters and pau
Dominik Huber wrote: Dominik Huber wrote: 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 This doesn't make any sense to me. If a programmers uses the trusted adapter facility, they do so exlicitly. The trusted adapter facility is documented to provide location. 0 Developer: Have to be aware of the location issue That's fine, because they are aware that they are using trusted adapters and the trusted adapter factory is documented to provide location. ... assert a location to all adapters: - Performance: Diffinitaly an overhead + Explicitness: Excplicit in relation to the location issue after adaption No, this is very implicit. It messes with *all* adapters, which is way too intrusive. Keep in mind too that proxies suck. They are deep magic, like metaclasses. Like metaclasses, they provide a powerful tool to solve extra hard problems, but they should be used sparingly. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://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
Re: [Zope3-dev] Form framework, adapters and pau
Dominik Huber wrote: Jim Fulton wrote: OK, here's an alternate proposal: If the permission attribute is used in the adapter directive and the permission is not zope.Public, then: If the adapter doesn't provide ILocation, we location proxy it and set the parent. If the adapter does provide ILocation and it's __parent__ is None, we set the __parent__. This will be accomplished with a custom factory. Does this make you happy? :) Yes, cool ;) Can I help anything or are you going to implement that code I don't think I'll have time to do this soon. Will this be for 3.1 or 3.2? Is it a feature or a bug fix? :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://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
Re: [Zope3-dev] Form framework, adapters and pau
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. Jim -- Garrett Dominik Huber wrote: 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=endep=/Mn4k.search=unnecessary expense se?lp=endep=/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
RE: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: 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. Are you referring to the problems Gary ran into when he modified the form setup machinery? I ran into the same problems in our application, which led to the mods to make LocationProxy work with security proxied objects. 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. Apart from the works/doesn't work issue (your previous point), are you concerned that we'll see LocationProxy popping up whenever we need location-sensitive lookups? Would that be a bad thing? I've found LocationProxy to be essential providing location-specific lookup capability in more than forms. E.g. I often location-proxy objects in events where handlers perform operations that want local authentication facilities. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Form framework, adapters and pau
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 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=endep=/Mn4k.search=unnecessary expense se?lp=endep=/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. - 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. Any objections? Regards, Dominik Huber ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
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. 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=endep=/Mn4k.search=unnecessary expense se?lp=endep=/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. - 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. Any objections? Yes. :) Why not simply use an untrusted public adapter? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://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
Re: [Zope3-dev] Form framework, adapters and pau
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=endep=/Mn4k.search=unnecessary expense se?lp=endep=/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:
