[jira] Closed: (JSPWIKI-472) userdatabase.xml gets corrupted after user registration when running on EBCDIC based platforms

["Harry Metske (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JSPWIKI-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harry Metske closed JSPWIKI-472.
--------------------------------

    Resolution: Fixed

Fixed in 3.0.0-svn-55 and 2.8.2-svn-6

> userdatabase.xml gets corrupted after user registration when running on EBCDIC based platforms
> ----------------------------------------------------------------------------------------------
>
>                 Key: JSPWIKI-472
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-472
>             Project: JSPWiki
>          Issue Type: Bug
>          Components: Authentication&Authorization
>    Affects Versions: 2.8.2, 3.0
>         Environment: JSPWiki 2.8.2
> Tomcat 5.5
> Java 6
> z/OS 1.8
>            Reporter: Harry Metske
>            Assignee: Harry Metske
>             Fix For: 2.8.2, 3.0
>
>         Attachments: JSPWIKI-472.patch
>
>
> Users logging in don't get their Favorites Menu showed anymore, also their G'day <name> greeting is not correct (shows userid instead of name).
> This happens after a new colleague tries to register a new user in JSPWiki.
> Analysis reveals that after the user has registered, an entry in userdatabase.xml is added with a password that has invalid XML characters, for example :
> <user uid="" loginName="hidden" wikiName="alsohidden" fullName="whatever" email="alice@wonderland.org" password="{SSHA}å̓ç¢é+/!ÎÑ>ì¦ÂÉëç‹Å (<>íí™å ¦!“ ã•î   " created="2009.01.20 at 14:02:35:461 CET" lastModified="2009.01.20 at 14:02:35:461 CET" lockExpiry="" >
> As a result the userdatabase.xml cannot be parsed anymore.
> Further code analysis brings me to AbstractUserDatabase that transforms a String to bytes with a hardcoded codepage of UTF8:
> {code}
> hash = CryptoUtil.getSaltedPassword( text.getBytes("UTF-8") );
> {code}
> Then the CryptoUtil does it's job, and finally returns a back converted string from a byte array without an encoding parameter :
> {code}
> return SSHA + new String( base64 );
> {code}
> Now, this almost always goes fine on ASCII based platforms, but it almost always fails on EBCDIC based platforms (yes yes , I know, the IBM Mainframe again).
> I will attach a patch for review, if there are no objections I'd like to commit it.
> I think it should be patched in both trunk and 2.8.2.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.