Open bviktor opened 8 years ago
My instinct would be to truncate the username from @
after successful auth within the LDAP provider. This would mean that a login of user.name@foobar.com
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.
I'm trying to find out which method is the common practice, but it seems to be different everywhere.
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.@
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.
This related to (or a possible duplicate of) #1079.
Related: #1012
After changing login from
sAMAccountName
tomail
, the user can log in no problem, but the personal repos are gone. This is because now Gitblit is looking for the personal repos undergit/~user.name@foobar.com
instead ofgit/~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:
So now I see 2 options:
StringUtils.findInvalidCharacter
to accept the@
characterThe 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?