Bug #672

Sunstone does not support extended ASCII characters inside the user password

Added by Daniel Molina over 9 years ago. Updated over 9 years ago.

Status:ClosedStart date:06/08/2011
Priority:NormalDue date:
Assignee:Hector Sanjuan% Done:


Target version:Release 3.0
Resolution:wontfix Pull request:
Affected Versions:


If the user password contains extended ASCII characters, the user is not able to log in (invalid username or password).


#1 Updated by Hector Sanjuan over 9 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 over 9 years ago

  • Status changed from New to Closed

Also available in: Atom PDF