username allowed characters

Wed Feb 22 11:04:58 UTC 2023

Hi

Well ... since you use @ in usernames, I think you *do* have an issue 
with the way Kallithea assumes emails and usernames are different 
"namespaces" (or rather "value spaces").

I'm reluctant to allow @ in usernames in general without making sure 
that it works correctly in all cases, without opening up for new problems.

As mentioned, one case that must be considered is when the username of 
one user is the email of another user. Some invariant would have to be 
enforced.

We need a convincing story of how get_by_username_or_email and all the 
invocations of it should handle emails as username. And there might be 
others.

It seems like in your setup, both kallithea/controllers/base.py and 
kallithea/lib/auth_modules/__init__.py will find the corresponding user 
object with get_by_username_or_email ... which will look up the user by 
matching on the email field. You say that "the mail address is still a 
different variable, but probably with the same content" ... but 
apparently it *must*  have the same content for your setup to work 
correctly. But then I don't understand what you say about the case where 
Email is different than the login.

Another potential problem that comes to mind is auto completion of 
usernames, for example in @mention. There might not be a problem there, 
but it would have to be verified.

So while it is great that it works for you with this minor change, I 
don't think it is a setup that can be recommended or that we would 
consider "supported". Fixing it properly would imply investing in bigger 
changes to the fragile and critical authentication system while making 
sure nothing breaks for other use cases.

For upstream Kallithea, I think it would be more feasible to expand ldap 
auth to allow login with email, but still use a "real" username without 
@ inside Kallithea ... assuming your ldap has another field that can be 
used for that purpose. But I don't know if that could work for you and 
with your IT department requirements.

/Mads

On 22/02/2023 10:34, svhb at telenet.be wrote:
> Hi Mads,
>
> I don't have issues with emails and usernames in different namespaces. 
> It is not my intention to use the "username" as email address, lets 
> keep them indeed separate. It is just problematic that the username in 
> my case also looks like an email address (with '@')
>
> As it happens, our IT-dept has a hard request to use the email to 
> login in systems, so I need to use the email as "Login Attribute" for 
> LDAPS (the AD attribute is called userPrincipleName but I don't know 
> if that is a standard), no problem here. The "Email Attribute" just 
> gets the same data, so for Kallithea, the mail address is still a 
> different variable, but probably with the same content.
> To complicate things further, this 'userPrincipleName' can be an 
> email-address on a different domain, than the standard 'Email 
> Attribute' for a specific user, in this case the Email is different 
> than the login.
>
> The issue arises when I want to change a setting on a user (for 
> example make someone admin), then the earlier 'valid' username is not 
> valid anymore. Hence, the little hack, just allow a slightly more 
> flexible rule to validate the username.
>
> Cheers,
>
> Stefaan
>
>
>
> ------------------------------------------------------------------------
> *Van: *"Mads Kiilerich" <mads at kiilerich.com>
> *Aan: *"vanheesbeke stefaan" <svhb at telenet.be>, "kallithea-general" 
> <kallithea-general at sfconservancy.org>
> *Verzonden: *Dinsdag 21 februari 2023 15:25:10
> *Onderwerp: *Re: username allowed characters
>
> Hi
>
> Thank you.
>
> But ...
>
> Kallithea generally tries to keep logins and emails unambiguous and in 
> different namespaces. It is arguably a bug if Kallithea allows LDAP to 
> use email addresses as usernames.
>
> The assumption is probably not entirely enforced, but it and the 
> consequences show up for example in get_by_username_or_email .
>
> If allowing @ in usernames, it should perhaps be enforced that it only 
> is allowed if it matches the email ... but that seems like a hack that 
> would be hard to enforce and not really feasible.
>
> But it is already generally possible to login with email instead of 
> username. Perhaps that doesn't work with LDAP? Can you set attr_login 
> to point at the email attribute? Or does that have other bad 
> consequences? Something that could be fixed instead?
>
> /Mads
>
>
> On 21/02/2023 12:03, svhb at telenet.be wrote:
>
>     Hello,
>
>     I'm using LDAP to authenticate users to our system. Out IT-dept
>     hammers on the fact that we need to use the email-address of users
>     to login.
>
>     The login works ok, but when I want to change the settings for a
>     certain user, it complains about a '@' in the user name.A simple
>     patch during docker build solved this issue.
>
>     Since email addresses are used regularly for logging in, maybe
>     this can be also in the next version of Kallithea.
>
>
>     Simply said : just adding @ to the regexp for username does the job.
>
>     --- validators.py    2023-02-21 10:25:27.657212999 +0000
>     +++ validators_new.py    2023-02-21 10:26:40.560218089 +0000
>     @@ -92,7 +92,7 @@
>                          msg = self.message('username_exists', state,
>     username=value)
>                          raise formencode.Invalid(msg, value, state)
>
>     -            if re.match(r'^[a-zA-Z0-9\_]{1}[a-zA-Z0-9\-\_\.]*$',
>     value) is None:
>     +            if re.match(r'^[a-zA-Z0-9\_]{1}[a-zA-Z0-9\-\_\.@]*$',
>     value) is None:
>                      msg = self.message('invalid_username', state)
>                      raise formencode.Invalid(msg, value, state)
>          return _validator
>
>     Cheers,
>     Stefaan
>
>
>     BTW : this is the best package I encountered since bitbucket
>     stopped with Hg.
>
>
>     _______________________________________________
>     kallithea-general mailing list
>     kallithea-general at sfconservancy.org
>     https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20230222/ffc6ab6b/attachment-0001.html>