[cgiapp] CAP::Authentication doesn't retain filtered credentials?

[Graham TerMarsch]

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 
this...

------------------------------------------------------------

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?

Thoughts? Comments?

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.

-- 
Graham TerMarsch
Howling Frog Internet Development, Inc.