-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin,
Wow. On 2/22/2009 8:52 PM, Martin Gainty wrote: >> Alan Chaney wrote: >> >> To summarize >> >> 1. password be case insensitive [I may be able to talk them out of this] > MG>handled from java.lang.String toUpperCase/toUpperCase > http://java.sun.com/javase/6/docs/api/java/lang/String.html He's trying to do a case-insensitive match in the database. Do you suggest executing "SELECT * FROM user" and then uppercasing every username looking for the right one? It's already been pointed out that many databases already perform case-insensitive CHAR/VARCHAR matching /and/ that not all databases have the same functions for performing this on the server-side (which is the only reasonable place to do it). >> 2. username be case insensitive. > MG>leave as case-sensitive What's the matter... you don't like the requirements? >> 3. email address can be used as a synonym for the user name. > MG>store email as a column in your users table Er... he's already got that. Have you been reading? >> 4. Security managed by Tomcat CMS. > MG>use Realm as earlier suggested storing user and role info in users and > user_roles tables > MG>respectively He's already doing that. >> Mark T suggested that I modify DSR appropriately. > MG>DSR is ready for deployment just match your tablenames for users and > user_roles > MG>also match your userNameCol and userCredCol and roleNameCol Not true... he wants to use /either/ username /or/ email address as the user identifier. >> Chris Schultz pointed out correctly that it gets a bit more complicated >> if the pwd must be hashed. > MG>no harm stick into Oracle DB as a Blob column (binary large object) or as > RAW Why would you bother doing that? The digester already provides the hashed password as a string, so putting it into a CHAR field makes more sense. >> I've looked at the code to DSR and it seems to me that the following >> would work. >> >> 1. add an 'alternative' userNameCol (eg altNameCol) and in the >> configuration as above point that at the email column. > MG>good.. > >> 2. in the code, IF the login fails using the 'user_name' then try it >> with the altNameCol. > MG>the result from action class will path you there ..but you're on the right > track.. Huh? >> Defaults could be chosen such that the current configuration setup still >> works (eg the default value for isCaseInsensitive is false) > MG>sensitive stuff like username/password goes in DB > MG>everything else to get the page up and running can go into a flat > file(.properties/stylesheets) Okay, my brain is hurting. What are you talking about? >> Only real gotcha that I can see for making it database independent is >> that the function used to create lower case is not univerally 'lower()' >> (M/SQL appears to be toLower()) so it might be necessary to pass the >> string for the function name as an optional configuration parameter. > MG>I've been working with Oracle recently MySQL last year and Oracle is > case-sensitive > MG>oracle!=ORACLE but MySQL will take upper/lower or camelcase queriesfor > same result If you mean that MySQL performs CHAR and VARCHAR comparisons without regard to case then yes, this is true. You can get case-sensitive matches by casting one of the operands to BINARY CHAR/VARCHAR. >> I realize that many people would advise against the idea of case >> insensitive passwords - however, despite my personal reservations I am >> willing to accept that in the case of this particular application the >> reduction in security is acceptable. > MG>decide on uppercase or lowercase and stick to it.. > >> If hashed pwds are used then there are 3 solutions: >> >> 1. don't allow case insensitive passwords - only user names. > MG>UserNames should be case sensitive AL != al (at least in Oracle) Dude. Read. The. Requirements. Nobody cares how you think things should be. This is a business requirement. You can't simply say "no". >> 2. provide two columns one for lower case versions of the pwd. > MG>not a good idea and violates data normalisation one copy in DB > MG>use uppercase or lower case only for view Two different passwords in the database is not denormalization. Whenever we change password strategies (it's happened twice), we store the old-style password in one column and the new-style password in another. After a while (usually like a year or more), we phase-out the old-style and suspend the logins of all the users who haven't "upgraded" their passwords. I think this is a perfectly reasonable strategy. >> 3. convert all the existing password HASHES to the lower case equivalent, > MG>wont work A (0x41) != a(0x61) ..you can assume tolower is a simple > addition of hex 20 > MG>when the hash algo gets ahold of the character the 0x41 hashes differently > than 0x61 This is a bad assumption as it only works with US-ASCII. This is not even true for the simple Latin charsets that are included in ISO-8859-1. He's talking about using a lowercase version of all passwords to generate hashes. These new-style hashes will be stored in the new-style column in the dat... Oh, forget it. We all know what's going on. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmiEsoACgkQ9CaO5/Lv0PCfbQCeJ2A0NU5uD4Zh0nzFUs94u1yA XzwAoKXxzjo3aPCv6UWKZXgFlON8HApX =Lv3s -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
