New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GUACAMOLE-1239: Make identifier comparison case-insensitive. #902
base: main
Are you sure you want to change the base?
Conversation
This looks reasonable to me, though I think it should be something that's determined by the implementation. What about adding a function like The other issue will be with database queries. IIRC, MySQL/MariaDB is case-insensitive for username queries, but PostgreSQL is case-sensitive. We would need to somehow allow for MySQL/MariaDB to optionally consider case and for PostgreSQL to optionally ignore case ... ideally without making any schema changes. |
Are you talking about the actual DB usernames (as in what would be configured in guacamole.properties), or just the normal string-based queries in the tables? These changes, here, shouldn't actually impact the Postgres (or MySQL or MSSQL) usernames and/or passwords that Guacamole uses to access the database, and I would think that all databases consider case when doing comparisons for |
I'm referring to comparisons against the When I try things against PostgreSQL,
When I try against MySQL, they're the same:
|
Got it - I'll take a run at it. |
The generally accepted method for PostgreSQL to do case-insensitive searches/comparisons seems to be to use the MySQL appears to have a couple of options:
|
@mike-jumper : So I take it you're thinking that this should be configurable - default to case-sensitive, perhaps, but with a |
I think the ideal would be a bit of a combination of all worlds:
Simply exposing whether identifiers are intended to be treated as case-sensitive or case-insensitive should already bridge a large gap. For example, if a user authenticates using a case-insensitive account via LDAP, a case-sensitive backend like PostgreSQL could intelligently and automatically choose to transform that identifier into a format that would not be affected by case sensitivity (lowercase? uppercase?). |
edb0e91
to
4c2f1ff
Compare
7ec5158
to
1bdfbe4
Compare
Converted to a draft for now - I think I've accomplished just about everything except the ability to force the JDBC modules to deal with usernames in one form or the other Testing so far shows that an LDAP username entered in a different case will 1) get permissions assigned in JDBC from the username regardless of case, and 2) will not create duplicate user entries auto-created in a Postgres database. |
1bdfbe4
to
de0d750
Compare
de0d750
to
580f710
Compare
580f710
to
9080074
Compare
I'm working through the JDBC changes required to make case sensitivity configurable, and I'm getting a bit confused in some of the mapper files. For example: Lines 26 to 32 in 3611be5
The Lines 30 to 33 in 3611be5
== EDIT Or am I missing something else, here? |
Here, since the relevant column from the database result is
I can't find any examples in the MyBatis documentation that show You're correct that absolutely all of the |
Appreciate any feedback you have on this most recent round of changes. I've spent some time trying to re-work the various JDBC modules to handle configurable case sensitivity settings. For each of the databases:
Aside from database-specific issues, the other big thing to look at is how I've actually changed the interfaces that MyBatis uses with its mapper files to generate the required code...
|
You should be able to query which collations are available on a database using So short answer no I don't know of a better way, sadly. This is all more of a pain than I would have ever guessed, but generally your approach looks pretty reasonable to me so far. |
Thanks for the feedback. Yeah, it seems like, even using the |
I suppose the other route to consider, here, is to make the JDBC changes specific to forcing the PostgreSQL module into case-insensitive mode, and not worry about the settings/options/changes that force MySQL and/or SQL Server into case-sensitive mode? It seems like the most frequent request is to make the look-ups and comparisons case-_in_sensitive, and since MySQL and SQL Server already do that by default, we could just go with that. @mike-jumper @jmuehlner Further thoughts? |
This is an attempt to make comparison of usernames case-insensitive, as most authentication systems do not distinguish between case in usernames. This goes about it by 1) converting all identifiers to lower-case, and 2) making the comparison of identifiers case-insensitive.
I'm really more doing this to get the conversation started on the best way to go about this. I realize that this method is a sort of atomic bomb approach - it's simple, but has a lot of (potentially negative) implications. It's also not in any way configurable. I'm happy to discuss other ways that we can accomplish it, but both personal experience with case-sensitive usernames in Guacamole along with the other folks who are asking for it makes me believe it's something we need to address.