<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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").<br>
</div>
<br>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">/Mads</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 22/02/2023 10:34, <a class="moz-txt-link-abbreviated" href="mailto:svhb@telenet.be">svhb@telenet.be</a>
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1383179661.17628328.1677058448482.JavaMail.zimbra@telenet.be">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div style="font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 10pt; color: #000000">
<div>Hi Mads, <br>
</div>
<div><br data-mce-bogus="1">
</div>
<div>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 '@')<br>
</div>
<div><br data-mce-bogus="1">
</div>
<div>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. <br
data-mce-bogus="1">
</div>
<div>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.<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>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.
<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>Cheers, <br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>Stefaan<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div><br>
</div>
<hr id="zwchr" data-marker="__DIVIDER__">
<div data-marker="__HEADERS__"><b>Van: </b>"Mads Kiilerich"
<a class="moz-txt-link-rfc2396E" href="mailto:mads@kiilerich.com"><mads@kiilerich.com></a><br>
<b>Aan: </b>"vanheesbeke stefaan" <a class="moz-txt-link-rfc2396E" href="mailto:svhb@telenet.be"><svhb@telenet.be></a>,
"kallithea-general"
<a class="moz-txt-link-rfc2396E" href="mailto:kallithea-general@sfconservancy.org"><kallithea-general@sfconservancy.org></a><br>
<b>Verzonden: </b>Dinsdag 21 februari 2023 15:25:10<br>
<b>Onderwerp: </b>Re: username allowed characters<br>
</div>
<div><br>
</div>
<div data-marker="__QUOTED_TEXT__">
<div class="moz-cite-prefix">Hi</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thank you.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">But ...</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The assumption is probably not
entirely enforced, but it and the consequences show up for
example in get_by_username_or_email .<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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?<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">/Mads<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 21/02/2023 12:03, <a
href="mailto:svhb@telenet.be" target="_blank"
rel="nofollow noopener noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">svhb@telenet.be</a> wrote:<br>
</div>
<blockquote>
<div style="font-family:'verdana' , 'arial' , 'helvetica' ,
sans-serif;font-size:10pt;color:#000000">
<div>Hello, <br>
</div>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
<div>Since email addresses are used regularly for logging
in, maybe this can be also in the next version of
Kallithea. <br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Simply said : just adding @ to the regexp for
username does the job. <br>
</div>
<div><br>
</div>
<div>--- validators.py 2023-02-21 10:25:27.657212999
+0000<br>
+++ validators_new.py 2023-02-21 10:26:40.560218089
+0000<br>
@@ -92,7 +92,7 @@<br>
msg =
self.message('username_exists', state, username=value)<br>
raise formencode.Invalid(msg,
value, state)<br>
<br>
- if
re.match(r'^[a-zA-Z0-9\_]{1}[a-zA-Z0-9\-\_\.]*$', value)
is None:<br>
+ if
re.match(r'^[a-zA-Z0-9\_]{1}[a-zA-Z0-9\-\_\.@]*$',
value) is None:<br>
msg = self.message('invalid_username',
state)<br>
raise formencode.Invalid(msg, value,
state)<br>
return _validator<br>
<br>
</div>
<div>Cheers, <br>
</div>
<div>Stefaan<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>BTW : this is the best package I encountered since
bitbucket stopped with Hg. <br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre">_______________________________________________
kallithea-general mailing list
<a href="mailto:kallithea-general@sfconservancy.org" target="_blank" rel="nofollow noopener noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">kallithea-general@sfconservancy.org</a>
<a href="https://lists.sfconservancy.org/mailman/listinfo/kallithea-general" target="_blank" rel="nofollow noopener noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.sfconservancy.org/mailman/listinfo/kallithea-general</a>
</pre>
</blockquote>
<p><br>
</p>
<br>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>