Bug 579766 - Installer UI inability to handle unicode means passwords can be incorrectly obfuscated.
Installer UI inability to handle unicode means passwords can be incorrectly o...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Installer (Show other bugs)
1.4
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: FutureFeature, i18n
Depends On:
Blocks: 579824
  Show dependency treegraph
 
Reported: 2010-04-06 09:57 EDT by Corey Welton
Modified: 2014-05-02 13:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 579824 (view as bug list)
Environment:
Last Closed: 2014-05-02 13:59:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Welton 2010-04-06 09:57:02 EDT
Description of problem:
User can enter unicode entities in the forms on the Installer UI, but these are not handled correctly.  The resulting mangled text is what gets obfuscated, versus the unicode entities.

Version-Release number of selected component (if applicable):


How reproducible:
Every time

Steps to Reproduce:
1. Unpack and start server.
2. "$JBOSSON_HOME/bin/generate-db-password.sh 你好"; observe results
3. In the password field, enter the characters '你好' and initiate install
4. After installer commences -- and possibly failed -- view results in rhq-server.properties
  
Actual results:

[root@core-01 bin]# ./generate-db-password.sh 你好
Encoded password: 68f725778bb36d3b
[root@core-01 bin]# grep "rhq.server.database.password" rhq-server.properties 
rhq.server.database.password=55a670d2613a05d127d3d58e7aa8e158df8592078de921bc


Expected results:

Password should match

Additional info:
I think what is happening is that the unicode characters, upon submit, are getting translated into their html entities -- so "你好" becomes "你好", which is in turn obfuscated.

We need to fix the UI to allow unicode input (preferable but intensive) and/or document whether we'll allow unicode characters in passwords.  As it stands, I suspect Oracle and perhaps Postgresql do both support it.
Comment 1 Charles Crouch 2010-04-06 10:33:17 EDT
Corey, can you check how we handle unicode passwords in 2.3.1? From your analysis if the installer really is converting these to html entities before storing them in rhq-server.properties, then unicode passwords will never have worked.

If thats the case, then I'm fine with making this an RFE and doc'ing this restriction for 2.4
Comment 2 Corey Welton 2010-04-06 11:28:13 EDT
I don't suspect this is a regression - in that sense, I agree that it's not necessarily something we need to 'fix' this release... however the new obfuscation tool introduces disparity.  As users previously hadn't been provided a clean route to enter unicode passwords, it was not as much an issue.  generate-db-password.sh, however, does allow it, so we're need to manage this in some way or another.

I am fine with a doc note.  I can mark this FutureFeature and get a docs issue written up.

Note You need to log in before you can comment on or make changes to this bug.