Bug 579824 - Release note: Installer UI inability to handle unicode means passwords can be incorrectly obfuscated.
Summary: Release note: Installer UI inability to handle unicode means passwords can be...
Alias: None
Product: RHQ Project
Classification: Other
Component: Documentation
Version: 1.4
Hardware: All
OS: Linux
medium vote
Target Milestone: ---
: ---
Assignee: Deon Ballard
QA Contact: Ian Springer
Depends On: 579766
Blocks: jon24-docs 577033
TreeView+ depends on / blocked
Reported: 2010-04-06 16:28 UTC by Deon Ballard
Modified: 2013-08-06 00:36 UTC (History)
3 users (show)

Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Clone Of: 579766
Last Closed: 2010-08-12 16:49:28 UTC

Attachments (Terms of Use)

Description Deon Ballard 2010-04-06 16:28:11 UTC
This bug needs to be added to the "known issues" section of the release notes.

A warning box must also be added to the install guide.

+++ This bug was initially created as a clone of Bug #579766 +++

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 

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.

--- Additional comment from ccrouch@redhat.com on 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

--- Additional comment from cwelton@redhat.com on 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.

Comment 1 Deon Ballard 2010-06-22 15:10:36 UTC
I have this under the "Server Config" section in the known issues:

Changing to ON_QA.

Comment 2 Deon Ballard 2010-06-22 15:47:40 UTC
I'm changing the QA contact to Andrew in ECS to take some of the pressure of the JON QE team. 

I'm putting Corey on as CC in case Andrew has any questions.

Comment 3 Ian Springer 2010-07-01 22:21:28 UTC
I've verified the note in the release notes - looks good to me. Including an example was a great idea.

Comment 4 Corey Welton 2010-08-12 16:49:28 UTC
Mass-closure of verified bugs against JON.

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