username allowed characters
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 +
+++ validators_new.py 2023-02-21 10:26:40.560218089 +
@@ -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@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
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, s...@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 +
+++ validators_new.py 2023-02-21 10:26:40.560218089 +
@@ -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@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: username allowed characters
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"
Aan: "vanheesbeke stefaan" , "kallithea-general"
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, [ mailto:s...@telenet.be | s...@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 +
+++ validators_new.py 2023-02-21 10:26:40.560218089 +
@@ -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 [ mailto:kallithea-general@sfconservancy.org |
kallithea-general@sfconservancy.org ] [
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general |
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general ]
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
Re: username allowed characters
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, s...@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" *Aan: *"vanheesbeke stefaan" , "kallithea-general" *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, s...@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 s
