| Request | LDAPMultiPlugins -- question -- by John Hannon |
| Posted on | Oct 5, 2006 6:22 pm |
| Subscribe |
| Comment by Jens Vagelpohl on Feb 10, 2007 8:56 am | |
|
Before trying to complicate things more, please try the new code and come back if there are any problems. |
|
|
|
| Resolve by Jens Vagelpohl on Feb 10, 2007 5:08 am | |
|
I have now switched the hash generation to use random numbers instead of time-based keys, and at least for the LDAPUserFolder instance the hash key is regenerated on every restart. http://svn.dataflake.org/?view=rev&revision=1385 |
|
|
|
| Comment by Marcin Cieslak on Jan 23, 2007 12:20 pm | |
|
Hallo! I had a similar problem AND your note helped to solve me it!!! I have two instances of LDAPUserFolder 2.6 connecting to the same LDAP server (ActiveDirectory). Those user folders had similar configurations _except_ for different group mapping. (You need to be in the AD group "A users" to access folder /a and you need to be in the AD group "B users" to access folder /b. Users complained that once their got roles to application B they cannot get roles for application A - and indeed, both LDAPUserFolders looked like they shared a common cache. I have checked this using "zopectl debug": app.a.acl_users._hash and app.b.acl_users._hash had the same value! The reason for this might be that we have copied objects using import/export facility from another zope server (development). Assigning a new hash solved the issue: >>> app.a.acl_users._hash="LDAPUserFolderAnotherHash" >>> get_transaction().commit() Also re-creating one of the LDAPUserFolders may help. In short: yes, _hash generation may need some improvement! Thanks for your posting - this helped me to solved this problem on my own. --Marcin Keywords: shared cache ldap roles authentication LDAPUserFolder mixed |
|
|
|
| Comment by Jens Vagelpohl on Nov 1, 2006 3:37 pm | |
|
John, do you know how to start a debugging session in Zope using zopectl debug? To find out if there is a clash I would need some information that is easiest to get from a debug session, or alternatively by writing an external method to get at an internal attribute used by the LDAPUserFolder LDAPDelegate class. What I need to see, from both these plugins, is the "_hash" attribute of the "_delegate" attribute on each acl_users inside the plugins. You could do this in the debug session: >>> p1 = app.unrestrictedTraverse('/path/to/acl_users/plugin1') >>> p1.acl_users._delegate._hash somestring >>> p2 = app.unrestrictedTraverse('/path/to/acl_users/plugin2') >>> p2.acl_users._delegate._hash anotherstring ... or this in an external method: def printhash(self): p1 = self.unrestrictedTraverse('/path/to/acl_users/plugin1') p2 = self.unrestrictedTraverse('/path/to/acl_users/plugin2') return (p1.acl_users._delegate._hash, p2.acl_users._delegate._hash) If these two hash values are the same, you have a clash and it means I need to change the way this hash is computed. |
|
|
|
| Initial Request by John Hannon on Oct 5, 2006 6:22 pm | |
|
I'm using 2 instances of LDAPMultiPlugins under PlonePAS in order to authenticate against 2 separate domains (extranet vs. internal). Without the RAMCache, I get lots of the error below. With cache turned on, it seems to work ok, at least with just me testing. Should I worry about this coming back to bite me when I have a bunch of concurrent users authenticating? Is it a bug? Any info would be most appreciated. John OPERATIONS_ERROR: {'info': '00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece', 'desc': 'Operations error'} 2006-10-05 14:04:33 ERROR event.LDAPDelegate {'info': '00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece', 'desc': 'Operations error'} Traceback (most recent call last): File "/dept/is/webgroup/zope/plone25_lecprod/Products/LDAPUserFolder/LDAPDelegate.py", line 337, in search res = connection.search_s(base, scope, filter, attrs) File "/dept/is/webgroup/zope/plone25_lecprod/Products/LDAPUserFolder/SharedResource.py", line 112, in __call__ return self._callable(*args, **kw) File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line 481, in search_s return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout) File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line 789, in search_ext_s return self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs) File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line 746, in _apply_method_s return func(self,*args,**kwargs) File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line 475, in search_ext_s return self.result(msgid,all=1,timeout=timeout)[1] File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line 405, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line 409, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line 415, in result3 rtype, rdata, rmsgid, serverctrls = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line 94, in _ldap_call result = func(*args,**kwargs) |
