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, [email protected] 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" <[email protected]>
*Aan: *"vanheesbeke stefaan" <[email protected]>, "kallithea-general"
<[email protected]>
*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, [email protected] 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
[email protected]
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
_______________________________________________
kallithea-general mailing list
[email protected]
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
