Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49A16E50.30907@compulsivecreative.com>
Date: Sun, 22 Feb 2009 07:25:04 -0800
From: Alan Chaney <alan@compulsivecreative.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Authenticating Users
References: <49A06A0A.503@compulsivecreative.com>
 <49A06CD8.5080701@apache.org> <49A1678F.8010700@christopherschultz.net>
In-Reply-To: <49A1678F.8010700@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org