Re: [Zope-dev] LDAPRoleTwiddler / BasicUserFolder
why is that code no longer referring to the real userfolder anymore? it should not make calls to authorize/identify/authorize on self but on the LDAPUserFolder it is using as the user source. jens On Thursday, Oct 17, 2002, at 03:39 US/Eastern, Dirk Datzert wrote: Hi all, I try to solve some problems with LDAPRoleTwiddler an inherited version from BasicUserFolder I currently use a validate()-function which I saw similar in BasicUserFolder and in LDAPRoleExtender (modifications from Shane) My problem is that if self.authorize(user, a, c, n, v, roles): return user.__of__(self) in validate() does not work, but return user.__of__(self) work better, but does not the same as the API (which I don't know) expect. Can anybody give a hint ? Regards, Dirk used python code: # This must stay accessible to everyone def validate( self, request, auth='', roles=_noroles ): The main engine v = request['PUBLISHED'] # the published object a, c, n, v = self._getobcontext(v, request) name, password = self.identify(auth) user = self.authenticate(name, password, request) if user is not None: if user is not None: # On my Test-System it works with authorize() # On my Integration-System it works only without authorize() #if self.authorize(user, a, c, n, v, roles): return user.__of__(self) # Could not twiddle a user. Defer to other user folders. return None def authenticate(self, name, password, request): super = self._emergency_user if name is None: return None if super and name == super.getUserName(): user = super else: user = self.getUser(name, password) if user is not None and user.authenticate(password, request): return user else: return None Dirk Datzert.vcf ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
I perhaps should have clarified that I need to be able to specify the name of the attributes or methods at run time, so ComputedAttribute unfortunately won't do the trick as you have to define each attribute/method you require in the class definition. ie. I need something like : def __getattr__(self,attr): if name in self.methodlist: do something return Implicit.__class__.__getattr__(self,attr) where self.methodlist is a list of strings that may change per instance and/or at runtime, or itself could be calculated at the time of doing the __getattr__ (eg self.getMethodList()). Sounds like you could use ZPatterns. If you do implement your own __getattr__, you might need to check if the object you want to return implements __of__, and return object.__of__(self) (or something like that). -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LDAPRoleTwiddler / BasicUserFolder
Hi Jens, why is that code no longer referring to the real userfolder anymore? it should not make calls to authorize/identify/authorize on self but on the LDAPUserFolder it is using as the user source. self.identify() should be the same as if getLUF().identify() since LDAPUserFolder and LDAPRoleTwiddler both inherited this from BasicUserFolder. self.authenticate() does a self.getUser() which refers to getLUF().getUser() and does twiddling in one step and return the right user-object which the API would expect. I think that self.authorize(user,...) is better than self.getLUF().authorize(user,...) because the authorize does the following in 1st line: def authorize(self, user,... ): (inherited from BasicUserFolder) user = getattr(user, 'aq_base', user).__of__(self) this would be different for self.authorize, where self would be the LRT and self.getLUF().authorize() where self would be the LUF. The user is seen in 2 different contexts by .__of__(self) . Maybe I'm think too complicated, Your opinion ? Regards, Dirk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LDAPRoleTwiddler / BasicUserFolder
being explicit is almost always better. you are relying on internal magic and it's not apparent from looking at the code you wrote. the validate implementation in the LDAPRoleExtender is the most correct one. shane worked on it for a while to make sure it does the most correct thing possible, and if anyone knows about the vagaries of acquisition/security and all its possible permutations it is him. jens On Thursday, Oct 17, 2002, at 08:37 US/Eastern, Dirk Datzert wrote: Hi Jens, why is that code no longer referring to the real userfolder anymore? it should not make calls to authorize/identify/authorize on self but on the LDAPUserFolder it is using as the user source. self.identify() should be the same as if getLUF().identify() since LDAPUserFolder and LDAPRoleTwiddler both inherited this from BasicUserFolder. self.authenticate() does a self.getUser() which refers to getLUF().getUser() and does twiddling in one step and return the right user-object which the API would expect. I think that self.authorize(user,...) is better than self.getLUF().authorize(user,...) because the authorize does the following in 1st line: def authorize(self, user,... ): (inherited from BasicUserFolder) user = getattr(user, 'aq_base', user).__of__(self) this would be different for self.authorize, where self would be the LRT and self.getLUF().authorize() where self would be the LUF. The user is seen in 2 different contexts by .__of__(self) . Maybe I'm think too complicated, Your opinion ? Regards, Dirk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
Casey Duncan wrote: __getattr__ hooks are evil, only to be used as a last resort. Are you So I've found, and heard! It didn't stop me from tyring, and I still don't see why they should be so hard so work with, difficult perhaps, but I wouldn't have though you needed to pull the seemingly impossible to have them work (with zope at least)! creating some sort of transparent proxy object? What exactly are you trying to do? I'm not getting a big picture here. And why do you need See my last post (I posted it before I saw this one sorry), but basically I want a link/reference type functionality that hooks in before containment acquisition, and I think I've worked it out another way to do it as per that post. to call the inherited __getattr__ from Implicit? Doesn't raising an AttributeError take care of this? Yes it does, but it wasn't so simple in this case (This is where the 'evil' you mentioned earlier comes in). Part of my problem was the need to call another class method on self which in turn needs to access a method on self that comes from containment acquisition on self, which would call my overridden __getattr__ and have an exception rasied due to not doing containment acquisition. This exeption would then be caught in the code calling the first __getattr__ call, and not the second. Can python not handle exceptions properly with recursive function calls, or was this my bad analysis and/or just being generally confused? One other way that may work is to be able to set methods on the object as it comes out of the ZODB for use, as I need to be able to get methods from other objects in the ZODB, something to explore... Anyone have any pointers on this one perhaps? Yes, but that would change the attributes and cause the ZODB to save them on commit (unless you use volatile '_v_' attrs). This might not be a bad thing. I might be able to use _v_ attrs, otherwise the storing bit would be very bad unless the store method was also overriden and they were deleted on the way out. Thanks, JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
There is no default or normal __getattr__. __getattr__ is defined only when you need abnormal ways of getting an attribute. Do you mean it only gets defined when standard (instance class based) searching methods fail? If I try a similar thing to this, I always end up getting the 'old' one being defined as just the 'raise' statement. Thats because ObjectManager doesn't have a __getattr__ . The good thing with Object Manager doesn't specifically, but Implicit does, you can see it if you print out its '__class__.__dict__'. this is that you don't have to bother about calling the normal __getattr__. You only need to implement __getattr__ if you want data that isn't attributes and has names that are only defined in runtime, to look like they are attributes. Exactly what I need! :-) Thankfully these methods that I need defined at runtime only come from one other object, so it appears I can override the __of__ method to work the magic for me in conjunction with containment acquisition. Thanks, JB. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LDAPRoleTwiddler / BasicUserFolder
Jens Vagelpohl wrote: being explicit is almost always better. you are relying on internal magic and it's not apparent from looking at the code you wrote. the validate implementation in the LDAPRoleExtender is the most correct one. shane worked on it for a while to make sure it does the most correct thing possible, and if anyone knows about the vagaries of acquisition/security and all its possible permutations it is him. :-) Well, I tried to get it right, but I'm sure I could have missed something. On Thursday, Oct 17, 2002, at 08:37 US/Eastern, Dirk Datzert wrote: Hi Jens, why is that code no longer referring to the real userfolder anymore? it should not make calls to authorize/identify/authorize on self but on the LDAPUserFolder it is using as the user source. self.identify() should be the same as if getLUF().identify() since LDAPUserFolder and LDAPRoleTwiddler both inherited this from BasicUserFolder. self.authenticate() does a self.getUser() which refers to getLUF().getUser() and does twiddling in one step and return the right user-object which the API would expect. I think that self.authorize(user,...) is better than self.getLUF().authorize(user,...) because the authorize does the following in 1st line: def authorize(self, user,... ): (inherited from BasicUserFolder) user = getattr(user, 'aq_base', user).__of__(self) this would be different for self.authorize, where self would be the LRT and self.getLUF().authorize() where self would be the LUF. The user is seen in 2 different contexts by .__of__(self) . Maybe I'm think too complicated, Your opinion ? The idea behind LDAPRoleExtender is to give the user global roles if the user accesses a context where extra roles would be given. In order to grant global roles, the context of the user is always the LDAPUserFolder, not the role extender. Role computation applied this way has a nasty side effect, unfortunately: if the user is allowed to write any kind of script, the user can access anything protected by the supposedly local roles. Don't ever grant the Manager role using LDAPRoleExtender unless you fully trust the user. I don't know anything about LDAPRoleTwiddler. But I would recommend you install the VerboseSecurity product, which will tell you a lot more about the Unauthorized error. And if you're interested, I know how we can make LDAPRoleExtender much safer, based on conversations with Jens. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to override __getattr__ and not break acquisition
From: John Barratt [EMAIL PROTECTED] Do you mean it only gets [called] when standard (instance class based) searching methods fail? Yes. At least, this is what the documentation sais, and it seems to be true as far as I can see. Object Manager doesn't specifically, but Implicit does, you can see it if you print out its '__class__.__dict__'. Ah, OK, I never did any really thorough research in that department. I have, in any case, gotten the same results as you, so in that case you probably need to call Implicits.__getattr__ directly. I haven't seen any negative effects of not doing this, though. I'm not well versed enough in how to write python stuff in c, so I don't understand it very well. Just well enough to not be able to find Implicits __getattr__. :-) Exactly what I need! :-) Thankfully these methods that I need defined at runtime only come from one other object, so it appears I can override the __of__ method to work the magic for me in conjunction with containment acquisition. Yup, much better way. __getattr__ is more for if you have a dictionary which data you want as attributes. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LDAPRoleTwiddler / BasicUserFolder
Hi Shane, thanks for answering. Maybe I'm think too complicated, Your opinion ? The idea behind LDAPRoleExtender is to give the user global roles if the I don't know anything about LDAPRoleTwiddler. But I would recommend you install the VerboseSecurity product, which will tell you a lot more about the Unauthorized error. The LDAPRoleTwiddler (LRT) should act as a LDAPUserFolder (LUF). He uses a LUF or a LRT in upper directory to retrieve the user data and changes the roles he got there depending on group-to-role mapping. example: user has following LDAP groups dir1_VISITOR, dir2_AUTHOR /acl_users (LUF) /dir1/acl_users (LRT) map dir1_VISITOR to role Visitor /dir2/acl_users (LRT) map dir2_AUTHOR to role Author the user has the roles Anonymous,Authenticated and Visitor in dir1. the user has the roles Anonymous,Authenticated and Author in dir2. the user has the roles Anonymous,Authenticated in alle other dirs. And if you're interested, I know how we can make LDAPRoleExtender much safer, based on conversations with Jens. Sure I'm interessted. Regards, Dirk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] LDAPRoleTwiddler / BasicUserFolder
if I access /dir2/index_html comes the user object from LRT2 ?
what if I access in /dir2/index_html aq_parent.dir1.index_html.
Will the AUTHENTICATED_USER change ? will the user object come from LRT2
?
No, it will not. Only one user ever applies to a request.
And that exactly what is my problem:
AUTHENTICATED_USER.has_permission('View', /dir1/index_html) always
returns 0,
if AUTHENTICATED_USER comes from /acl_users and doesn't take care about
the local roles coming out of /dir1/acl_users .
What is about the strategy I was talking about getRolesInContext ?
Dirk
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Improving ZSQL Methods
Hmm... (a) Is a great idea (b) How would this work in practice? Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk - Original Message - From: Andy McKay [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 11:07 PM Subject: [Zope-dev] Proposal: Improving ZSQL Methods I've put up a proposal I'd like to put into 2.6.1 or 2.7, whichever is next. Summary: Change ZSQLMethods to allow a user to a) change the database connection without changing the object and b) use standard cache managers. http://dev.zope.org/Wikis/DevSite/Proposals/ZsqlMethodImprovements Any comments or ideas welcome. Cheers. -- Andy McKay www.agmweb.ca ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Improving ZSQL Methods
(b) How would this work in practice? Make a RAM Cache Manager, and then assign the ZSQL Method to cache in that cache manager, just like you would any other object. The results are then cached according to the database connection and the query in the RAM Cache Manager. It means we have a much more flexible and powerful caching mechanism available that is not thread specific. -- Andy McKay www.agmweb.ca ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Reports of CallProfiler not working with Zope 2.5.x were greatly exagerated :-) (was Re: CallProfiler?)
On Fri, 18 Oct 2002 6:07 am, Leonardo Rochael Almeida wrote: CallProfiler wasn't profiling ZPTs because they've been renamed/moved from Products.PageTemplates.PageTemplates.PageTemplates to Products.PageTemplates.ZopePageTemplate.ZopePageTemplate. Here's a patch to make it work again. I'll see about patching it and release a new version for 2.5 (not supporting 2.4 any more). BTW, does anyone know what a MLDTMLMethod from a MLDTML product (in CallProfiler/CallProfiler.py:124-125) is? It's our in-house multilingual support ;) Anyway, I'm still wondering whatever happened to the CallProfiler integration plans. I see there are anthony-CallProfiler-something branches in CVS, but I couldn't make anything of them (probably my CVS inexperience). Anyone knows anything about this? Sorry, both Anthony and I ran out of tuits before the 2.6 release. I believe the final integration was simply lost somewhere between Anthony and Brian - but they'd know what the exact situation is. PS: Richard, I'm CCing this to you because you mentioned you're accepting patches and I don't know if you subscribe to zope-dev. Thanks, but I'm on -dev ;) Richard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
