Bug #672
Sunstone does not support extended ASCII characters inside the user password
Status: | Closed | Start date: | 06/08/2011 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | Hector Sanjuan | % Done: | 0% | |
Category: | Sunstone | |||
Target version: | Release 3.0 | |||
Resolution: | wontfix | Pull request: | ||
Affected Versions: |
Description
If the user password contains extended ASCII characters, the user is not able to log in (invalid username or password).
History
#1 Updated by Hector Sanjuan about 10 years ago
- Resolution set to wontfix
OpenNebula is saving special characters as scaped string in the datatables:
User "ñ" becomes <NAME>ñ</NAME>
Making the comparison between the user input field and the database username difficult.
Additionally in order to get the "ñ" correctly on the server side, there is a problem regarding rack basic auth. Rack auth module decodes the Authentication base64 string as UTF-8. However, this string is normally encoded by Firefox and Chrome (if all chars are allowed) as if it was ISO-8859-1. The page charset must then be set to ISO-8859-1 or some forbidden codes will appear on the base64 string when decoding. That said, Rack is decoding this string and assiging UTF-8 encoding. string.force_encoding("ISO-8859-1") must be done on the server side in order to have ruby interpret the string correctly as "ñ". From there, it can (and should be converted) to real UTF-8 in order to be able to make comparisons with UTF-8 strings from the database. (string.encode("UTF-8")).
Tried unsucessfully to find a Sunstone workaround for all this. But as long as OpenNebula is not saving "ñ" and others in the database as what they are (or at least extracting them and turning ñ into "ñ"), this has not much sense and will keep special characters as unsupported.
#2 Updated by Ruben S. Montero almost 10 years ago
- Status changed from New to Closed