Hmm, it would be interesting if there was an alternative, but really the problem lies in the database. Any wildcard type searches (at least that start with a wildcard) are not likely to use indexes and cause a table scan. If your database supported the concept of having case-insensitive indexes, then I would think it would be pretty trivial to implement in your own qualifier. In Sybase (the database I use mostly) you can create a functional index (an index based on a function), but it’s the equivalent creating a second column that’s always lower and maintaining an index on it. The difference being that the database maintains it for you (which is usually annoying for EOF).
I’ve always wanted a better way to do this too. -Lon On Wed, Feb 24, 2016 at 5:13 PM, Paul Hoadley <[email protected]> wrote: > Hello, > > Say you have a web application where the login identifier is the user’s > email address. This works in the conventional way: the user supplies that > address at sign-up, and it serves two in-app functions: login identifier, > and actual email address to which notifications can be sent. This is a > fairly common pattern among some large, modern web apps. > > It turns out that not everyone understands case sensitivity. We are seeing > login failures in the wild because a user that signed up as “ > [email protected]” is now trying to log in with “[email protected]”, > or vice versa. Here are some facts: > > 1. It would seem to be at least reasonably common for modern web apps that > use email addresses as login identifiers to ignore case at login time. (For > example, I tested a couple I had open in browser tabs: Strava and Bitbucket > ignore case.) > > 2. Although the domain part of an email address is case-insensitive, my > understanding is that the relevant RFCs suggest that you shouldn’t make > assumptions about the local part. While everything I’ve read claims that in > practice it will make no difference, let’s assume that we need to preserve > the address as entered at sign-up. (It’s fail-safe to do so, whether we > strictly need to or not.) > > So, 1 is our aim: ignore case on the login identifier at login time. But > because of 2, we don’t want to, say, normalise the email address given at > sign-up to lower case and just store that, on the off chance that it makes > a difference for mail delivery for that particular user. (Again, it > probably won’t, but let’s assume that it could for the exercise.) > > What are our options for finding the right User entity at login time? > > 1. We can jump in and naively use a CaseInsensitiveLike qualifier, but > then a user can stick ‘?’ and ‘*’ wildcards in the input. We could strip > those out, but they’re actually both valid characters in the local part. I > stopped short of trying to escape them, as this route is starting to seem a > little dangerous. > > 2. We could track both the supplied and a lower-cased version of the > identifier in separate attributes. This has the advantage of presumably > working, but it’s awkward, requiring special attention to changing the > normalised attribute when the user-supplied one changes. > > Can anyone suggest a better way? What I really need is a > CaseInsensitiveEquals qualifier, like Java’s equalsIgnoreCase(). Is there > such a thing? Would it be easily implemented? > > > -- > Paul Hoadley > http://logicsquad.net/ > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/webobjects-dev/lon.varscsak%40gmail.com > > This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
