Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: I already raised the question what the precedence should be if the OK, I'll anser that. If a permission is used in an adapter directive, it takes precedence over declarations made in a class directive. (In the future, I'd like to change the way security declarations work so that, perhaps, they are set on a name-by-name basis. So then, declarations for names in other interfaces wouldb't be lost when making a declaration for an adapter to a particular interface.) Excuse me wasting your time, I was wrong. I think the current proposal is: 1. provide an explicit locate attribute. This should be steaightforard. 2. if a non-public permission was specified, then behave as if a locate attribute was used. This seems straightforward too. Yes, I'm still aware of that proposal. It's implemented now. So, after all I would be ready now to check in :) I don't see what the problem is. After your adjustment I think it's only a 'little' problem if the 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
Dominik Huber wrote: (This mail seems to be lost some where so I take another try.) Sorry if this was my fault. Hi Jim, I cleaned up the locatableadapters-branch, but I did not implement an additonal locate attribute to the adapter directive yet, because it's pretty tricky to separate trusted-ness from location-ness. How so? I already raised the question what the precedence should be if the OK, I'll anser that. If a permission is used in an adapter directive, it takes precedence over declarations made in a class directive. (In the future, I'd like to change the way security declarations work so that, perhaps, they are set on a name-by-name basis. So then, declarations for names in other interfaces wouldb't be lost when making a declaration for an adapter to a particular interface.) 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 (experimental verification only). I couldn't tell you what the precedence should be because I didn't anticipate that someone would do both. The precedence is I don't see this. The _protectedFactory sets the __Security_checker__ regardless of whether it is already set. Also making declarations with the class directive does not set __Security_checker__ attribute on the class. zope.security.checker.ProxyFactory) checks for __Security_checker__ before looking for class-based declarations. Therefore we can't use the permission attribute of the Sorry, I don't see this. Given the above precedence fact, I cannot imagine a way how to resolve your (Jim's) requirement 'trusted-public-adapters-should-not-be-location-proxied' and the requirement within a local authentication any permission unless zope.Public does require location-ness. For that reason I sugest to stay with the current implementation of the branch (30225) and cancel the locate-extension. I think the current proposal is: 1. provide an explicit locate attribute. This should be steaightforard. 2. if a non-public permission was specified, then behave as if a locate attribute was used. This seems straightforward too. I don't see what the problem is. 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
(This mail seems to be lost some where so I take another try.) Hi Jim, I cleaned up the locatableadapters-branch, but I did not implement an additonal locate attribute to the adapter directive yet, because it's pretty tricky to separate trusted-ness from location-ness. I already raised the question what the precedence should be if the 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 (experimental verification only). I couldn't tell you what the precedence should be because I didn't anticipate that someone would do both. The precedence is Therefore we can't use the permission attribute of the Given the above precedence fact, I cannot imagine a way how to resolve your (Jim's) requirement 'trusted-public-adapters-should-not-be-location-proxied' and the requirement within a local authentication any permission unless zope.Public does require location-ness. For that reason I sugest to stay with the current implementation of the branch (30225) and cancel the locate-extension. 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: 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 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: ... 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
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 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: ... In this case you'd get the location even though the adapter directive doesn't specify a permission. 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: So at the moment I do not see any another possibility to set those permissions than using an additional 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 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: 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 (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 any permission within 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 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 I didn't follow all of that... 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. OK, this is an imporovement. Within the current branch there are the three adapter factories: - PartiallyLocatingTrustedAdapterFactory - LocatingTrustedAdapterFactory - TrustedAdapterFactory You can easily switch them with
Re: [Zope3-dev] Form framework, adapters and pau
Dominik Huber wrote: Jim Fulton wrote: ... 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. Sure, but I would use different adapters to different functions. How can you handle the set and read aspects of a schema-based interface in two different adapters? Good point. You can't unless you use accessors. The permission is not a discriminator within the adapter directive. That's a bureaucratic solution ;) So at the moment I do not see any another possibility to set those permissions than using an additional 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. ... 2. the resulting adapter requires the permission defined by 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: Here, we are *explicitly* saying that we want to combine an aplication factory with a location proxy. This works for the example above. 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 (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 any permission within 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 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 I didn't follow all of that... 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. OK, this is an imporovement. 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 optimu
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 any permission within 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 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] 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: 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. Sure, but I would use different adapters to different functions. How can you handle the set and read aspects of a schema-based interface in two different adapters? The permission is not a discriminator within the adapter directive. That's a bureaucratic solution ;) So at the moment I do not see any another possibility to set those permissions than using an additional 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. ;) 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 If the permission is other than zope.Public, it gets a location. This can be a documented feature of the directive. 2. the resulting adapter requires the permission defined by 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. 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 (experimental verification only). 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) 2. the zwiki bug and my related implementations bugs still exists, because regularly folks that registering trusted adapters using any permission within 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 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. Within the current branch there are the three adapter factories: - PartiallyL
Re: [Zope3-dev] Form framework, adapters and pau
Dominik Huber wrote: 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: 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. Sure, but I would use different adapters to different functions. So at the moment I do not see any another possibility to set those permissions than using an additional 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. 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 If the permission is other than zope.Public, it gets a location. This can be a documented feature of the directive. 2. the resulting adapter requires the permission defined by 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. - 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? Most adapters don't need to be protected at all. There are lots of uses for adapters from trusted code. Note that null adapters are really only useful as factories that are looked up based on the interfaces that they implement. 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... :( Now I have no idea what you mean. 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? 2. if we register a trusted adapter this correlation breaks because the adapter instance itself might have highly differented security-permission (compare 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 :) It might be everyday for you, but definately not for me. In any case, I'm not willing to implicitly location-proxy all adapters. That's very intrusive and unacceptable. KeyReferences have no reason whatsoever to be locations. They are publically available. The only reason they "needed" to be locations was because of your implicit add
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: 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 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 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 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 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. - Therefore the adapter instance will not have any location. - Therefore we can't invoke the local authentication. My suggestion: IMO the intid and keyrefernce stuff is an exceptional case. Nobody else using the zope framework tries to memorize adapters persistently. The problem is that we were being too intrusive. Most adapters are never security proxied. We shouldn't implicitly add location proxies. We should only add them if we know we need them. Maybe I was focused to much to the existing implementation. We location proxy the trusted adapters only if they get protected by adapter factory. if an protected object is adapted: we assert a location (if no location is provided we use location proxy) else: we only set the __parent__ attribute if it is None Everyone is aware that adapters regularly are very transient. If somebody needs a pickable adapter he should be aware that those adapter must provide ILocation
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: 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: 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 ( adapter factories within the adapter directive processing.. So, during the registration of an trusted adapter factory ( 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 this correlation breaks because the adapter instance itself might have highly differented security-permission (compare In a complex situation like this, I suggest it's better to have people make their adapters locations in Python. 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 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. - Therefore the adapter instance will not have any lo
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: 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: permission declaration of the possible adapter instances ( adapter factories within the adapter directive processing.. So, during the registration of an trusted adapter factory ( 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 register a trusted adapter this correlation breaks because the adapter instance itself might have highly differented security-permission (compare 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 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. - Therefore the adapter instance will not have any location. - Therefore we can't invoke the local authentication. My suggestion: IMO the int
Re: [Zope3-dev] Form framework, adapters and pau
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: 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. So, during the registration of an trusted adapter factory ( permission declaration of the possible adapter instances ( adapter factories within the adapter directive processing.. 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. All the same I implemented your sugestion. The following question appears: - How should we handle NullAdapters correctly? What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. 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. 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. 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
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: So, during the registration of an trusted adapter factory ( permission declaration of the possible adapter instances ( adapter factories within the adapter directive processing.. All the same I implemented your sugestion. The following question appears: - How should we handle NullAdapters correctly? IMO this solution is pretty implicit and I do not like it at all. 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? Of course, you should revert the change to key references. Done [...] P.S. Please make sure source lines are 79 characters or less in lengnth. :) Ok Thank you for the comments! Regard, 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
Dominik Huber wrote: Jim Fulton wrote: 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? :) 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! This looks great, however, it points out a serious problem with implicitly proxying adapters. You proxy adapters that don't require a permission. This led to the breakage you encountered with key references. 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. Of course, you should revert the change to key references. I'd be happy to look at this again when you're done. Thanks. Jim P.S. Please make sure source lines are 79 characters or less in lengnth. :) -- 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: 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? :) 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! 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
Behalf Of Jim Fulton > Sent: Friday, April 08, 2005 5:35 PM > To: Dominik Huber > Cc: Garrett Smith; [EMAIL PROTECTED]; zope3-dev@zope.org > Subject: 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? :) This is a bug fix. If we use local authentication (PAU). The checker used in the editform will lookup in the global registry for principal permissions. Because the method canWrite looks up the permission with "thread_local.interaction.checkPermission(permission, object)" this ends in a bug if no location is provided. Regards Roger Ineichen > 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/dev%40projekt01.ch > > ___ 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
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 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
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? :) Jim Dominik Huber wrote: Jim Fulton wrote: Whether something is trusted or not is an implementation decision of the adapter. Yup. But if developer 'A' writes a framework such as the form framework, he does not implement the adapter himself. The adapters are implemented by others within different application for example developer 'X' and 'Y'. So the code of 'A' adapts something: >>> adapted = ISomething(context) >>> doLocationSensitiveStuff(adapted) 'A' is not able to influence the implementations of 'X' and 'Y' ISomething-adapters. If 'X' or 'Y' does register an none-public-untrusted adapter 'A's framework will fail. So 'A' has to force anyway all adapters to be locatable, if he wants handle this bug situation: >>> locatetable_adapted = assertLocation(ISomething(context), context) >>> doLocationSensitiveStuff(locatetable_adapted) I thougth, you (Jim) wanted to ban such dedicated location proxy stuff out of the code. Therefore you proposed the trusted adapter factory solution. My exclusive objection is that we don't get rid of specific location assertions within frameworks unless we make all adapters locatable. [...] > So are you agreeing with the proposal to add location proxies in the adapter factory and not in the form machinery? No. IMO we can not solve the problem correctly doing the location proxies inside the trusted adapter factory, because their might be a few untrusted adapters that requires a dedicated permission, too. So we have to do the proxying inside the trusted adapter factory and inside the form machinery and that's kind of pointless to me. 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. The mail before I asked you (Jim): How can I ask for trusted adapters explicitly inside a framework such as edit view? Your answer: You can't. May that's the key for our mutual misunderstanding (and of course my english) :) 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. IMO the mess starts when I don't know what I'm going to get *extra* out of an adapter call, for example >>> adapted = ISomething(context) and I have to introspect the result set before I can proceed because I might get an location for free ;) In all those cases where ISomething does not extend ILocation, it's pretty implicit to asume to have gotten a locatin too, except their would be the absolute rule and single exception ILocation is provided in any case. If we like to solve such a problem explicitly without such absolute commitments, we have to invent beside the existing Multi*For*Adapters the Multi*Provides*Adapters: >>> something_with_location = zapi.queryMultiProvideAdapter(context, (ISomething, ILocation)) or >>> something_with_location = zapi.queryMultiForAndProvideAdapter((context,), (ISomething, ILocation)) IMO such a solution would be explicit with no bad aftertaste, but it will probably break a few basic registry implementations. 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. YUP! Because the location proxying within the trusted adapter factory does not solve all my problems and I have still to go with dedicated framework solutions like proposed in the form machinery. I would suggest to straiten for dedicated framework solutions only and offer a helper function only. Regards, Dominik -- 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: Whether something is trusted or not is an implementation decision of the adapter. Yup. But if developer 'A' writes a framework such as the form framework, he does not implement the adapter himself. The adapters are implemented by others within different application for example developer 'X' and 'Y'. So the code of 'A' adapts something: >>> adapted = ISomething(context) >>> doLocationSensitiveStuff(adapted) 'A' is not able to influence the implementations of 'X' and 'Y' ISomething-adapters. If 'X' or 'Y' does register an none-public-untrusted adapter 'A's framework will fail. So 'A' has to force anyway all adapters to be locatable, if he wants handle this bug situation: >>> locatetable_adapted = assertLocation(ISomething(context), context) >>> doLocationSensitiveStuff(locatetable_adapted) I thougth, you (Jim) wanted to ban such dedicated location proxy stuff out of the code. Therefore you proposed the trusted adapter factory solution. My exclusive objection is that we don't get rid of specific location assertions within frameworks unless we make all adapters locatable. [...] So are you agreeing with the proposal to add location proxies in the adapter factory and not in the form machinery? No. IMO we can not solve the problem correctly doing the location proxies inside the trusted adapter factory, because their might be a few untrusted adapters that requires a dedicated permission, too. So we have to do the proxying inside the trusted adapter factory and inside the form machinery and that's kind of pointless to me. 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. The mail before I asked you (Jim): How can I ask for trusted adapters explicitly inside a framework such as edit view? Your answer: You can't. May that's the key for our mutual misunderstanding (and of course my english) :) 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. IMO the mess starts when I don't know what I'm going to get *extra* out of an adapter call, for example >>> adapted = ISomething(context) and I have to introspect the result set before I can proceed because I might get an location for free ;) In all those cases where ISomething does not extend ILocation, it's pretty implicit to asume to have gotten a locatin too, except their would be the absolute rule and single exception ILocation is provided in any case. If we like to solve such a problem explicitly without such absolute commitments, we have to invent beside the existing Multi*For*Adapters the Multi*Provides*Adapters: >>> something_with_location = zapi.queryMultiProvideAdapter(context, (ISomething, ILocation)) or >>> something_with_location = zapi.queryMultiForAndProvideAdapter((context,), (ISomething, ILocation)) IMO such a solution would be explicit with no bad aftertaste, but it will probably break a few basic registry implementations. 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. YUP! Because the location proxying within the trusted adapter factory does not solve all my problems and I have still to go with dedicated framework solutions like proposed in the form machinery. I would suggest to straiten for dedicated framework solutions only and offer a helper function only. 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
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: ... 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: 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 assert a location to all adapters: - Performance: Diffinitaly an overhead + Explicitness: Excplicit in relation to the location issue after adaption + Developer: Can forget about the location issue ___ 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: - 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
RE: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: > Subject: Re: [Zope3-dev] Form framework, adapters and pau > > > Here's an alternate proposal: > > Let's put the proxying in the trusted adapter factory. > > Let's make the trusted adapter factory add the proxy > if the adapter doesn't set ILocation. Then the form code > stays clean and other code will benefit. This would become > part of the definition of trusted adapters. > > If there are no objections, let's do it this way. > > Jim This is definitely better. It follows the pattern of the container machinery wrapping contained objects that don't provide IContained. -- Garrett ___ 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: Here's an alternate proposal: Let's put the proxying in the trusted adapter factory. Let's make the trusted adapter factory add the proxy if the adapter doesn't set ILocation. Then the form code stays clean and other code will benefit. This would become part of the definition of trusted adapters. If there are no objections, let's do it this way. +1 It's a positive convergence from adapters and content components. - 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. > In cases 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. In general, adapters are rarely accessed from untrustes code and are rarely security proxied. I would not want to location proxy them in general. Question: 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. 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: Here's an alternate proposal: Let's put the proxying in the trusted adapter factory. Let's make the trusted adapter factory add the proxy if the adapter doesn't set ILocation. Then the form code stays clean and other code will benefit. This would become part of the definition of trusted adapters. If there are no objections, let's do it this way. +1 It's a positive convergence from adapters and content components. - 1 It might be a trap too, because developers must be aware of the pretty implicit differnces between trusted and unstrusted adapters. In cases 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? Question: Then we have to build location proxies most of the time. Is that not a performance issue? ___ 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
Here's an alternate proposal: Let's put the proxying in the trusted adapter factory. Let's make the trusted adapter factory add the proxy if the adapter doesn't set ILocation. Then the form code stays clean and other code will benefit. This would become part of the definition of trusted adapters. If there are no objections, let's do it this way. Jim Jim Fulton wrote: Garrett Smith wrote: 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. OK 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. My main objection is that it seem too implicit to me. My objection is that we would be doing something for the adapter that it should have done for itself. With this change every adapter that doesn't provide ILocation will get proxied even if the adapter is actually public. I'm willing to give in on this though. If y'all want to change this back, I'll go along as long as it doesn't break things. :) 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: My main objection is that it seem too implicit to me. My objection is that we would be doing something for the adapter that it should have done for itself. With this change every adapter that doesn't provide ILocation will get proxied even if the adapter is actually public. I'm willing to give in on this though. If y'all want to change this back, I'll go along as long as it doesn't break things. :) Cool, I'm going to revert tomorrow (Excuse my discussion absence, I was out of the office yesterday.) Should I write an extra test for this change? If yes, where should I place this test for best (dependencies) 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
Hi Jim Behalf Of Jim Fulton > Sent: Tuesday, April 05, 2005 11:09 PM > To: Garrett Smith > Cc: [EMAIL PROTECTED]; zope3-dev@zope.org; Dominik Huber > Subject: Re: [Zope3-dev] Form framework, adapters and pau > > Garrett Smith wrote: > > 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. > > OK > > >>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. > > My main objection is that it seem too implicit to me. Yes, I think also the first time this is to implicit. But after many discussions with Dominik I changed my mind. We have two solutions. a) Use ILocation as default in adapters b) proxy location if needed I think since we allow location less content, the solution a) is easier right now. But I'm sure we run into this problem more the once in the future. Solution b) provide ILocation in adapters as default is also not this bad, but I think that this is most the time a overhead and needs some basic conceptual changes. > My objection is that we would be doing something for the adapter > that it should have done for itself. With this change every adapter > that doesn't provide ILocation will get proxied even if the adapter > is actually public. > > I'm willing to give in on this though. btw, it could be that this is not the last solution. I think after some time and more development with site specific components there will be a better understanding what's the best practice. Then we can decide if we really need ILocation in adapters or if this is a good concept. > If y'all want to change this back, I'll go along as > long as it doesn't break things. :) Of corse Regards Roger Ineichen > 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/dev%40projekt01.ch > > ___ 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: 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. OK 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. My main objection is that it seem too implicit to me. My objection is that we would be doing something for the adapter that it should have done for itself. With this change every adapter that doesn't provide ILocation will get proxied even if the adapter is actually public. I'm willing to give in on this though. If y'all want to change this back, I'll go along as long as it doesn't break things. :) 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
Hi Jim, Garrett and Dominik > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Garrett Smith > Sent: Tuesday, April 05, 2005 7:22 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; zope3-dev@zope.org; Dominik Huber > Subject: 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 1+ I think its the right solution since you fixed the location proxy and security proxy problem. Regards Roger Ineichen > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ 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: > 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
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 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
RE: [Zope3-dev] Form framework, adapters and pau
I don't understand the pushback against location proxying security-proxied objects. LocationProxy does actually play well with security-proxied objects. -- 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 >>> 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 s
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 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
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 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
