1. Marcin Kuzminski
  2. RhodeCode

Issues

Issue #298 resolved

Conflicting e-mail addresses for LDAP and RhodeCode users.

Anonymous created an issue

Scenario:

1) Create a user with an e-mail address someone@somecompany.com from the interface.

2) Login a user with the very same e-mail address someone@somecompany.com using LDAP.

3) Try to change settings for the LDAP user in RhodeCode, e.g. assign admin rights.

==> Problem: Notification in UI : "This e-mail address is already taken" Settings cannot be stored.

Comments (5)

  1. Matt Zuba

    I'm having this same issue as well. Any word on what might be causing it?

    I should note that I don't recall this happening when I was using sqlite for the DB for testing, but I'm using MySQL in production.

  2. Marcin Kuzminski repo owner

    well, sqlite sucks at constraints, so that's why it might not raise an error.

    When doing step1 step2 should be not possible. That might be a bug. Need to check.

    But in general you SHOULD NOT create users for them to be able to log in using ldap, RhodeCode will do that for you when user logs in for the first time.

    Can i see DB dump for those conficting users ?

  3. Matt Zuba

    Sorry, I guess I should have been more clear on my comment - I'm only experiencing the error when using LDAP users who are logging in and being created by RhodeCode.

    I narrowed down the issue to model/forms.py in the UniqSystemEmail def. It would appear that during user creation, the email address from LDAP is being stored in whatever 'case' form it is retrieved from LDAP (in my case, Matt.Zuba@domain.com). The UniqSystemEmail method is taking the value passed from the form and converting it to lower case, and then doing a quick IF to see if the old value and new value match... since Matt.Zuba@domain.com doesn't equal matt.zuba@domain.com to Python, the check fails, a DB query is done to see if the 'new' value exists, which it does, since MySQL isn't case sensitive, which then causes the whole validation to fail.

    This is how I fixed it on my end (maintains the case of the email address and properly validates)

    def UniqSystemEmail(old_data):
        class _UniqSystemEmail(formencode.validators.FancyValidator):
            def to_python(self, value, state):
                if old_data.get('email').lower() != value.lower():
                    user = User.query().filter(User.email == value.lower()).scalar()
                    if user:
                        raise formencode.Invalid(
                                        _("This e-mail address is already taken"),
                                        value, state)
                return value
    
        return _UniqSystemEmail
    

    I was going to submit a pull request for you, but I'm not sure what branch you're working off of.

  4. Marcin Kuzminski repo owner
    • changed status to open

    I'd guess the best solution would be to add a custom setter for models to always save email lowercase. mixed case emails doesn't make sense. Having this it would solve such problems system wide. I'll prepare something like that for beta branch test it, and than apply proper fix to default branch.

    Ps. everything goes always to beta-branch than get's ported to default(stable)

  5. Log in to comment