Yes, I think it was the conclusion to which we were coming with Massimo
that were making my modification to web2py not acceptable...

The check has to be done in LDAP contrib... The problem at this level is to
have access to web2py validators, if I remember we can't easily import
them, we have to copy them which is not DRY...

I can attach here my actual version of ldap_auth if you want... I saw a
couple modifications pass throught PR request or on this list though, so it
may be out of date...

But you can see what I actually do that solved this issue for me for now...

Richard

On Thu, Jan 8, 2015 at 6:29 PM, Carlos Hanson <car...@clanhanson.com> wrote:

> I'm not talking about forcing username only in all cases. Since I know
> that for this application and my LDAP server configuration, usernames are
> okay, so I think that having the option to force a particular login methon
> is useful.
>
> Then we can say login_with_email=False, or something of that nature, and
> get an error message that says logging in with email addresses is not
> allowed.
>
> I'll keep playing with it, since I need a way to prevent a user from
> accidentally creating a second account. Plus, I need to figure out why some
> account, and not all, are getting a duplicate created. That doesn't make
> sense.
>
> If I find something useful and relatively simple, I'll make another
> suggestion to get some feedback.
>
>
> On Thursday, January 8, 2015 at 2:37:15 PM UTC-8, Richard wrote:
>>
>> I think we can't restrick using only username because AD may have been
>> configure to use email address... To me, if I remember, the problem where
>> coming from ldap_auth contrib that is overly convoluted regarding the way
>> it manage login of user, transforming it from email to username to email...
>> In addition not all the variant of ldap use the same code regarding login
>> so... But it only some thoughts I didn't read the code since then and I
>> prefered to patch web2py which was making sure there were no email used as
>> login name. But I think it were not working for web2py and can't be
>> included in web2py code base.
>>
>> Richard
>>
>>
>>
>> On Thu, Jan 8, 2015 at 5:21 PM, Carlos Hanson <car...@clanhanson.com>
>> wrote:
>>
>>> I definitely like and agree with your idea about using
>>> get_or_create_user() in a login_method that intends to create (or get) a
>>> user, but that doesn't eliminate the duplicate entry problem. Perhaps, my
>>> suggestion isn't the best for eliminating it either, since it would require
>>> an update to ldap_auth.
>>>
>>> I also just realized that it is only a few users that are getting
>>> duplicate user accounts created. I am uncertain what would cause the
>>> problem in a subset of new accounts and not all, so my case just got more
>>> confusing.
>>>
>>> I can't find a way to prevent logging in with an email address. If it
>>> doesn't exist, then perhaps we just need to be able to tell
>>> get_or_create_user() to not use the full email. Then it would be more
>>> likely to find the existing user created by ldap_auth.
>>>
>>>
>>> Carlos
>>>
>>>
>>> On Thursday, January 8, 2015 at 12:01:03 PM UTC-8, Richard wrote:
>>>>
>>>> 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 <car...@clanhanson.com>
>>>> 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 <car...@clanhanson.com
>>>>>> > 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 web2py+un...@googlegroups.com.
>>>>>>> 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 web2py+un...@googlegroups.com.
>>>>> 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 web2py+un...@googlegroups.com.
>>> 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 web2py+unsubscr...@googlegroups.com.
> 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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to