I guess any solution si welcome, I didn't have spare time to work on this and because of the many ldap system to be tested against the change to be made I have been reluctante to work on this scince could be very long to finish the refactoring... :(
Richard On Thu, Jan 8, 2015 at 2:49 PM, Carlos Hanson <[email protected]> wrote: > Greetings, > > I've been humming along quite nicely until I released a new application > last month which is used by our entire staff rather than our department. > Now I have run into the duplicate user problem, but I looked through the > code and figured out why. I had forgotten that you mentioned it to me in > this thread. > > After reviewing your suggested solution and seeing that it has not been > implemented, I thought we might consider an alternative. Since Auth has > get_or_create_user() and it is called by Auth.login(), isn't it reasonable > to think that a particular login_method can also create a user? Given that > ldap_auth is already doing so, I suggest that we ask the login_method for > the user. If we get it, use it. If not, Auth can use its > get_or_create_user(). > > For example, in tools.py starting at line 2467: > > # try alternate logins 1st as these have the > # current version of the password > user = None > for login_method in settings.login_methods: > if login_method != self and \ > login_method(request.vars[username], > request.vars[passfield]): > if not self in settings.login_methods: > # do not store password in db > form.vars[passfield] = None > try: > user = login_method.get_user() > except AttributeError: > # login method has not implemented get_user() > pass > if user is None: > user = self.get_or_create_user( > form.vars, settings.update_fields) > break > > > > On Friday, August 16, 2013 at 3:10:36 PM UTC-7, Richard wrote: >> >> Hello Carlos, >> >> Yes you have to pass the db, doc is pretty un clear. Also, it stop >> working because when to tell to manage_user=True it start to check the >> credential against Active Directory. If you read the doc carefully you will >> discrover that if there is a password in the password field it will be >> prioritise on the AD credential. And if I remember my test, when >> Imanage_user is activating the password is cleared on user update >> (auth_user record is updated each time the user is login on). So, then the >> db become essential to allow ldap_auth to authentify user that was not the >> case before because it was web2py normal authenfication mecahnism which was >> a priority. >> >> Notice that ldap_auth contrib is not preventing logon with email as >> username, see this thread : https://groups.google.com/d/ >> msg/web2py/sEpOWYk0mFA/XOivgLvR0rEJ >> >> So, take care, because if you don't add padding, since you have activate >> management of user, new user (duplicate user) will be added with email as >> username. Massimo is aware (see thread) I suggest a patch but he is still >> in reflexion. You can apply the patch in the mean time to prevent >> duplicated user. But it may have backward compatibility issue (I don't >> know). There is also an other option, refactor ldap_auth and make it return >> validation error on email input as username, but it requires that we don't >> break ldap_auth. If you are in to refactor we can check what we could do. >> >> Also, I read that manage user =True is not working properly, so better >> leave it to false, I think. >> >> >> Hope it helps. >> >> Richard >> >> >> >> >> >> >> On Fri, Aug 16, 2013 at 1:22 PM, Carlos Hanson <[email protected]> >> wrote: >> >>> I am using ldap_auth. The following example shows an error I received >>> after adding manage_user=True. It is unclear to me why this is a problem. >>> >>> >>> ldap_auth_aux = ldap_auth(mode='ad', >>> ... server='my.domain.controller', >>> ... base_dn='ou=Users,dc=domain,dc=com', >>> ... filterstr='objectClass=*', >>> ... manage_user=True, >>> ... user_firstname_attrib='givenName', >>> ... user_lastname_attrib='sn', >>> ... user_mail_attrib='mail') >>> >>> import logging >>> >>> logger = logging.getLogger('web2py.auth.ldap_auth') >>> >>> logger.setLevel(logging.DEBUG) >>> >>> >>> ldap_auth_aux('chanson', '********') >>> DEBUG:web2py.auth.ldap_auth:mode: [ad] manage_user: [True] custom_scope: >>> [subtree] manage_groups: [False] >>> INFO:web2py.auth.ldap_auth:[my.domain.controller] Initialize ldap >>> connection >>> INFO:web2py.auth.ldap_auth:[chanson] Manage user data >>> Traceback (most recent call last): >>> File "<console>", line 1, in <module> >>> File "/srv/www/web2py/gluon/contrib/login_methods/ldap_auth.py", line >>> 421, in ldap_auth_aux >>> user_in_db = db(db.auth_user.email == username) >>> AttributeError: 'NoneType' object has no attribute 'auth_user' >>> >>> >>> ldap_auth_aux('chanson', '********', db=db) >>> DEBUG:web2py.auth.ldap_auth:mode: [ad] manage_user: [True] custom_scope: >>> [subtree] manage_groups: [False] >>> INFO:web2py.auth.ldap_auth:[my.domain.controller] Initialize ldap >>> connection >>> INFO:web2py.auth.ldap_auth:[chanson] Manage user data >>> True >>> >>> db.commit() >>> >>> >>> The Traceback in the error ticket showed one of the following prior to >>> the error on line 421 in ldap_auth_aux: >>> >>> - File "/srv/www/web2py/gluon/tools.py", line 2123, in login >>> - File "/srv/www/web2py/gluon/tools.py", line 2144, in login >>> >>> The interesting code is the following: >>> >>> login_method(request.vars[username], >>> request.vars[passfield]): >>> >>> db is not passed to the function. The function definition of >>> ldap_auth_aux has db=db, but the function is defined in ldap_auth which >>> defaults to db=None. I am not sure how it worked before. My solution is to >>> add db=db to my login_methods definition: >>> >>> auth.settings.login_methods = [ >>> ldap_auth(...as usual..., >>> manage_user=True, >>> user_firstname_attrib='givenName', >>> user_lastname_attrib='sn', >>> user_mail_attrib='mail', >>> db=db >>> ) >>> ] >>> >>> >>> I also noticed that the user_xxx_attrib values are case sensitive. For >>> example, I use givenName for the user_firstname_attrib. Searching ldap is >>> case insensitive, so I think the results should not be, but the results >>> create a dictionary which has case sensitive keys. In my case, if I use >>> givenname, which is the norm for me when I interact with ldap, line 665 of >>> ldap_auth.py throws an exception and my first_name in the auth_user table >>> gets created or updated to None, depending on whether the user exists or >>> not. >>> >>> I don't know if this needs to be changed necessarily. I think it would >>> be better to be case insensitive, since searches are that way, but if not, >>> at a minimum the documentation should say it that the case of the attribute >>> should match the schema definition. >>> >>> I'm not sure how to resolve the db=db issue above other than the way I >>> did, since I am unclear why it worked before I added manage_user=True. >>> >>> Carlos Hanson >>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "web2py-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
