mike-jumper commented on PR #1028:
URL:
https://github.com/apache/guacamole-client/pull/1028#issuecomment-2424691511
Yes and no. That would be an alternative and consistent approach. Taking a
mammoth step back to the beginning, I think we have two mutually-exclusive
possible approaches:
1. Identifier case sensitivity is defined by the extension _consuming_ the
identifier.
- This is what you're describing above and what I was describing
initially.
- This is invitingly simple, particularly for cases where there's only
one thing consuming identifiers.
- This feels a little odd, since it's the producer and not the consumer
that determines the intent of the identifier, but it does mean there is no
ambiguity in handling identifier comparisons.
- This might make sense only in light of a single, global property for
case sensitivity ... which is admittedly also invitingly simple.
2. Identifier case sensitivity is defined by the extension _producing_ the
identifier.
- This is what I was describing most recently.
- This is more complex, but allows the intent of an identifier to be
communicated.
- This feels cleaner, but introduces ambiguity around how case-sensitive
and case-insensitive identifiers could be compared. Then again, encountering
that explicit ambiguity might be an opportunity to log a warning that makes
identifier case sensitivity mismatches easier to notice and remedy.
Migrating to the former would mean getting rid of `isCaseSensitive()`,
instead relying purely on configuration properties determining how usernames
should be handled, and considering whether there should be any
extension-specific case sensitivity properties (since having intentionally
mixed case sensitivity would be bad practice).
Migrating to the latter would mean keeping `isCaseSensitive()`, clarifying
the properties as controlling the case sensitivity of the usernames of users
authenticated by and/or stored by that extension.
I find myself flipping back and forth between these without a clear answer
as to which is truly best. I suspect that's probably also why the current
approach is a sort of mix of these - they're both reasonable approaches.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
