Can't access or create personal repos when using userPrincipalName or mail LDAP attribute for login

[bviktor]

Related: #1012

After changing login from sAMAccountName to mail, the user can log in no problem, but the personal repos are gone. This is because now Gitblit is looking for the personal repos under git/[email protected] instead of git/~user.name.

The obvious solution would be to rename all these directories, but Gitblit won't recognize them even after being renamed.

It's odd, but you realize where the problem is when you try to create a new personal repo:

Illegal character '@' in repository name!

So now I see 2 options:

• use mail for logging in, but trim anything after @ for determining the personal repo path - just like GitBucket
• modify StringUtils.findInvalidCharacter to accept the @ character

The 2nd option is trivial to do, but a lot of other parts of Gitblit use this method so this needs to be tested thoroughly.

What's your opinion, guys?

[gitblit]

My instinct would be to truncate the username from @ after successful auth within the LDAP provider. This would mean that a login of [email protected] would be referred to as user.name everywhere in Gitblit: urls, paths, mentions, etc. Preserving the @ within the username has other unwanted side-effects like complicating or breaking mentions.

So while truncating the username fixes data and filesystem problems, does it lead to collisions? I'm thinking it can but it is relatively safe to assume that most installs using LDAP are for single-domains.

As an added auth step we could/should ensure the Gitblit account email address matches the login account address, if an address is supplied. But we should still document this collision possibility for multi-domain LDAP setups.

[bviktor]

I'm trying to find out which method is the common practice, but it seems to be different everywhere.

• GitBucket: trim - this can cause collisions, though not too often
• Redmine: use sequential numerical IDs - IMO this isn't desirable because it relies on a solid database and syncing. A users.conf that's actually generated from LDAP isn't really such a DB. The LDAP users are there regardless of users.conf - imagine you delete users.conf to reset/refresh user info or fix a file corruption, then because of LDAP user changes, some people are assigned a different ID.
• Jenkins: use full username - this seems to be the most robust (@ is totally valid on any file system I can think of), but as you mentioned, prolly this involves the most work too.

I personally like the full username one. Anyway, could you please clarify on "mention" ? Now I've tried to use @user.name in a ticket comment but it only highlighted user, i.e. it breaks at the dot.

[flaix]

This related to (or a possible duplicate of) #1079.