Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
I was the OP on this one. Mark just made a couple of suggestions.
On 2/21/2009 4:06 PM, Mark Thomas wrote:
5. Patch DataSourceRealm
6. Make case sensitivity configurable and contribute your patch back to
the ASF.
7. Use securityfilter to write your realm, and not be tied to Tomcat.
Had a brief look at 'securityfilter' - however we actually do require
container managed security as we have several applications. Other
alternative as previously mentioined is acegi.
8. Many databases use case-insensitive string comparisons already.
Case-insensitive passwords (probably a bad idea!)
Actually, in general, I agree that its a bad idea. However, each case
has to be handled in the light of the actual users expectations.
In the case of this specific application the users are artists who are
generally extremely computer naive. We commonly get support enquiries
"I can't log into my account" EVEN THOUGH we have sent them their
account names and passwords because they are not correctly capitalizing
their usernames or passwords.
It is important to keep to keep the case of usernames because, as I
said, they are artists, and the capitalization may have significance to
them as part of their brand.
The information on the site is publically available after it has been
published. There is no commercial or sensitive information on the site.
will work if you
aren't hashing them. If you are, you'll have to lowercase them or something.
Exactly. One problem for a general solution is that there are variations
in the name of the 'lowercase' function between databases. So far, I've
found that Postgres, MySQL and Oracle appear to support 'lower()' but
M/SQL has it as tolower() (thanks again MS)
If you /are/ hashing them, you'll need to do a password migration where
anyone who changes their password gets it lowercased but passwords that
existed beforehand are still case-sensitive. You cannot avoid this, now
matter what your solution is.
In this specific case at the moment we aren't hashing them, but you
raise a good general point about hashing which I'll have to think about.
Regards
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
