Hans Desmet (Migrated from SEC-1463) said:
The following users (see reference documentation), defined in XML, can login:
When the usernames begin with a capital, those users can't login.
When submmitting the default form generated by you get an error: Your login attempt was not successful, try again. Reason: Bad credentials
When you define users in a datbase (via ) this problem doesn't occur.
Luke Taylor said:
Usernames aren't case insensitive. The code that checks this is the same - it only depends on the UserDetailsService, so it is most likely something to do with your database schema setup. If you disagree, please provide evidence that you can load an upper case name from a database and authenticate against it.
Hans Desmet said:
The problem occurs when you define the users in XML, NOT when you define them in a database.
You can see the problem with following app (STS project in attach)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
When you open the webapp with your browser and you type joe as username and joe as password you see index.html
When you open the webapp with your browser and you type Jack as username and jack as password you see following error:
Your login attempt was not successful, try again.
Reason: Bad credentials
Ah, Ok. I thought you were saying that the lookup was case-insensitive with the database, but not with the in-memory provider. Looking at the code, it turns out that The in-memory UserDetailsService is supposed to be case insensitive (names are stored in lower case). For some reason This seems to be an issue with 3.0.x branch but not the master branch. The namespace parsing code creates a separate map without lower-case usernames. I will correct this and update the documentation to clarify that the username is case-insensitive for users.
The UserMap class should also be deprecated and the code for the in-memory UserDetailsService simplified.
Wojciech Owczarczyk said:
I think this problem still persists (tested on Spring Security 3.1.0)
This issue is related to #1704