The user model validates usernames on
/\A[[:alnum:]_-@.]*\Z/
but the login controller attempts to login by downcasing the username.
This leads to valid usernames which can not login. Is the preferred
issue to fix the validation, or stop downcasing at login?
– bk
are logins downcased everywhere such that you ensure that you can't have
the following entries in in the user table:
login:id
user1:1
UseR1:2
USER1:3
or is that denied?
If we are downcasing, what is the rationale? Seems odd for a user to
create a user with a login of: MikeMcCune and then after the fact we
downcase it to mikemccune
Mike
> The user model validates usernames on
>
> /\A[[:alnum:]_-@.]*\Z/
>
> but the login controller attempts to login by downcasing the username.
> This leads to valid usernames which can not login. Is the preferred issue
> to fix the validation, or stop downcasing at login?
+1 for downcase.
Ohad
– bk
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
hello list,
Here I have a case where usernames were defined uppercase to match the
samaccountname attribute in each person certificate (that way we can do SSO
for foreman web ui).
In that case, if you force the loginname to be lowercase, will it still
work for my current case? I will not be able to change the certificate
attribute in this organisation.
Claer
Today this can exist (well, no : but the rest). And, if the passwords
match, USER1 will log in as user1.
No, that’s allowed — although you can’t actually login with UseR1 or USER1 because of the downcasing.
I would vote to remove the downcasing and leave case-sensitive handling. The justification being that’s the POSIX standard for usernames is case-sensitive and that seems as good a standard as any to follow IMHO.
On 02/24/2014 10:18 AM, Bryan Kearney wrote:
The user model validates usernames on
/\A[[:alnum:]_-@.]*\Z/
but the login controller attempts to login by downcasing the username.
This leads to valid usernames which can not login. Is the preferred
issue to fix the validation, or stop downcasing at login?are logins downcased everywhere such that you ensure that you can’t have the following entries in in the user table:
login:id
user1:1
UseR1:2
USER1:3or is that denied?
–
Stephen Benjamin
stephen@bitbin.de
Or maybe not, some interesting history: https://bugzilla.redhat.com/show_bug.cgi?id=954128
Just keep in mind if you go the only downcase route a user could someday come around that has a case-sensitive auth source, which is possible with LDAP (e.g. default with IBM http://www-01.ibm.com/support/docview.wss?uid=nas7f3b0e0a21b53f868862578ce005d0ec5)
"IPA does not support case sensitive users by design. The main reason is that ldap is historically case insensitive for user accounts. It is a mismatch between POSIX and LDAP standards. MSFT corrected it by doing it on the server because they control both server and the client. We put a lot of thought into this and you can dig IPA and SSSD mail archives for details however the solution we came up which seems most flexible is to enforce low case in IPA and allow SSSD to be configured to treat the source of the identity information case sensitive or case insensitive.”
No, that’s allowed — although you can’t actually login with UseR1 or USER1 because of the downcasing.
I would vote to remove the downcasing and leave case-sensitive handling. The justification being that’s the POSIX standard for usernames is case-sensitive and that seems as good a standard as any to follow IMHO.
–
Stephen Benjamin
stephen@bitbin.de
I second that, and further add that if we can store case-sensitive
names in the DB, lowercasing them at this point could potentially lead
to duplicates which would be hard to resolve in a migration (e.g.
Mike's example would become 3 duplicates of the same login, so which
roles do you keep?).
Greg
TBH… I am fine with enforcing lowercase in the short term since it
makes everything consistent (only take in data which can work). Then, if
folks want an RFE for case sensitive that can be added to a consistent
model.
– bk
That seems reasonable. I opened a redmine (and PR) for the downcasing, 4439.
TBH… I am fine with enforcing lowercase in the short term since it makes everything consistent (only take in data which can work). Then, if folks want an RFE for case sensitive that can be added to a consistent model.
–
Stephen Benjamin
stephen@bitbin.de
If there are mixed case users out there, they weren’t ever able to login anyway. I
seems the intention was to always have lower case usernames. I think it’s
fine as long as it’s consistent, since there’s two conflicting ways (POSIX,
and LDAP/IPA/AD)
On 24 February 2014 23:22, Stephen Benjamin stephen@bitbin.de wrote:
No, that’s allowed – although you can’t actually login with UseR1 or USER1 because of the downcasing.
I would vote to remove the downcasing and leave case-sensitive handling. The justification being that’s the POSIX standard for usernames is case-sensitive and that seems as good a standard as any to follow IMHO.
I second that, and further add that if we can store case-sensitive
names in the DB, lowercasing them at this point could potentially lead
to duplicates which would be hard to resolve in a migration (e.g.
Mike’s example would become 3 duplicates of the same login, so which
roles do you keep?).Greg