LDAP login with mail or userPrincipalName: Invalid pattern for attribute 'username' - possible workaround

Hi

I’ve come across gitea and wanted to see if I could get it to work with our LDAP directory so students could use their credentials they already have.

Since this is an AD LDAP environment, using the userPrincipalName is perfectly valid for binding instead of sAMAccountname (which wuild be uid in OpenLDAP).

The UPN looks like a mail address and usually it is recommended to have it the same as the mail address. (Avoids trying to explain users the difference between mail and userPrincipalName as most will see @ and thus conclude it is the same)

The UPN is the username students have to use for any federated athentication anyway (as sAMAccountname is not accepted there) so I’d like to use it there as well.

Gitea will stop me doing so with with the error in the logs: “LDAP login with mail or userPrincipalName: Invalid pattern for attribute ‘username’”

Now I’ve tried building gitea by simply yanking out the line that does the validation in models/login_source.go.

As Lauris mentioned in #5444 that "@ can not be added as allowed character as [it] could lead to side effects". - I could quickly confirm that cause with issues in the repository URLs during checkouts (which contain ‘@’).

However I wanted to discuss a middleground that might lead to solution, however I consider myself far from familiar enough to realize the extend of this change…

EDIT: What about first matching the username against the EmailPattern first, and if it does, amend it by replacing i.e. by “at” and then do the check with AlphaDashDotPattern like it already does?

models/login_source.go

func LoginViaLDAP([...]

    // WiP: UPN workaround
    if binding.EmailPattern.MatchString(sr.Username) {
        sr.Username = strings.Replace(sr.Username, "@", "_at_", -1)
    }

    // Validate username make sure it satisfies requirement.
    if binding.AlphaDashDotPattern.MatchString(sr.Username) {
    [...]

It may absolutely be that I’m overlooking something that might have really horrible side-effects … so I really appreciate your input before proposing a pull request.