[
https://issues.apache.org/jira/browse/GUACAMOLE-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888083#comment-17888083
]
Mike Jumper commented on GUACAMOLE-1239:
----------------------------------------
[~vnick] - I think the issue here is that we are effectively explicitly
instructing MyBatis to use the old function and query, and that doesn't match
what's declared. While {{getObjectMapper()}} returns the correct type of
mapper, the function calls on that mapper are specifically things like
{{select(identifiers)}} and not {{select(identifiers, caseSensitive}}:
{code:java}
objects = getObjectMapper().select(chunk);
{code}
Unless _that_ call is updated to make use of the {{caseSensitive}} function,
then we're calling what we're calling. MyBatis will instead use the proxy
function that _is_ explicitly called, which doesn't match the needs of the
query declared in the XML.
To fix this, I think all implementations of the mapper functions which now
accept {{caseSensitive}} will need to be rolled into a single implementation
that all mappers share, even though the connection, connection group, etc.
implementations of that would be unmodified since those identifiers are
inherently case-insensitive here (numeric).
I'd say:
# Ensure all mapper functions that were modified to support {{caseSensitive}}
({{select()}}, etc.) are instead modified to support this at the _base_ level.
# Modify the base object service that defines {{getObjectMapper()}} to pull
whether identifiers for the mapped objects are case-sensitive from some
abstract function.
# Ensure that abstract function returns {{false}} for objects with inherently
case-insensitive identifiers and pulls the value from configuration otherwise.
With everything then in agreement on what parameters are provided to what, the
error should go away.
> Make usernames case insensitive in DB
> --------------------------------------
>
> Key: GUACAMOLE-1239
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1239
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, guacamole-auth-jdbc,
> guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-auth-ldap
> Reporter: Magnus Lübeck
> Assignee: Nick Couchman
> Priority: Minor
> Fix For: 1.6.0
>
>
> [~cameronp] already summarized this well in GUACAMOLE-404:
>
> Quote:
> "We have ldap auth working for us via active directory. We have issues with
> case senstivity around logins. For example most users have no idea if their
> username is
> User.Name
> or USER.NAME or whatever. - active directory doesnt care about case, and
> neither does ldap authentication.
> But when they log in to guac and do not match the case of their login
> exactly, guac allows them to log in, but they just don't have any machines to
> connect to.
> Wondering if it could be made to either fail the logins if it doesn't match
> correct case, or ignore case when matching the username in the local guac db."
>
> So, when I ran across GUACAMOLE-404, and this email
> [https://www.mail-archive.com/[email protected]/msg03715.html] where
> [~vnick] discuss this topic in depth, I realized that I need to chip in my
> point of view. In the documentation it is mentioned that one can restrict
> user login, to avoid confusion that a user can log in per LDAP but not have
> any connections,
> http://guacamole.incubator.apache.org/doc/gug/jdbc-auth.html#jdbc-auth-restrict.
> I am not sure where I would start lobbying for either asking for a default
> case insensitive username management, or the option to make the
> Postgresql/Mysql/etc usernames case insensitive. I would happily chip in
> time, money, or other stimulus to bring this discussion further.
>
> This writeup from google is a text I have visited from time to time, as I
> think it is well written and makes many points in a clear manner.
> [https://cloud.google.com/blog/products/gcp/12-best-practices-for-user-account]
>
> Point 11: Make user IDs case insensitive
> Quote:
> "Your users don't care and may not even remember the exact case of their
> username. Usernames should be fully case-insensitive. It's trivial to store
> usernames and email addresses in all lowercase and transform any input to
> lowercase before comparing.
> Smartphones represent an ever-increasing percentage of user devices. Most of
> them offer autocorrect and automatic capitalization of plain-text fields.
> Preventing this behavior at the UI level might not be desirable or completely
> effective, and your service should be robust enough to handle an email
> address or username that was unintentionally auto-capitalized."
>
> I had a very long discussion about this with a work colleague today. He has
> to support a group of customers, of which we get a list of CAPITALIZED
> usernames to import into our Active Directory domain controller. These users
> are quite used to work in an environment where they don't have to care. I
> have observed our customers log in and many users either log in with their
> username in lowercase, some log in with their username's first letter
> CAPITALIZED. Very rarely do they log in with all caps.
>
> To make matters a bit worse, is that we integrate Guacamole with oauth2_proxy
> in front of it. Oauth2_proxy sends the users first to our KeyCloak
> installation, which happily authenticates the user with any permutation they
> choose to enter. Since we do want to have the users log into the RDP servers
> with their own credentials they are asked to log in again (a 2nd time, since
> we don't get the password through otherwise). It is very confusing for our
> users that they can log into KeyCloak but not into Guacamole.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
