[cgiapp] CAP::Authentication doesn't retain filtered credentials?
cgi-application at howlingfrog.com
Sat Dec 1 16:45:27 EST 2007
I've gone and created a ticket in RT for this (#31133), but wanted to also
ping the list and see what other suggestions/thoughts might come up out of
In my application we allow users to authenticate by "e-mail address", which is
stored internally in all lower-case.
Users, however, have a tendency to want to log in using mixed-case addresses
like "BobUser at AOL.com".
I've been able to see that I can filter the credentials used to match up with
the values in my DB (so that works), but the problem that I end up with is
that all calls to "$self->authen->username()" still return the
original -mixed-case- version that the user provided.
This then causes some other things to go astray:
- our post-login callback which keeps a "last login date/time" up-to-date for
users has to be sure to force the username to lc() before using it,
- CAP::Authorization breaks, as when it queries things in the DB its getting
the MiXeD cAsE version of the email address to query with (and thus isn't
finding any matches).
Although I'd love to see "$self->authen->username()" return the filtered
version of the username, I'd also expect that this would cause grief for
other people who've built things up on the premise that "you get back what
the user entered, unfiltered".
How about a "$self->authen->filtered_username()" method?
Or, am I overlooking a simpler answer entirely? Right now I'm handling this
via a "post-login callback", where I query the username, force it to lc(),
then set it back into the store. Works, but feels hack-ish.
Howling Frog Internet Development, Inc.
More information about the cgiapp