Cannot login with password containing non-ascii characters

Hello,
I have web application, form based login. UTF-8 is specified "everywhere".
And it works, except for passwords.
If user register itself with password containing non-ascii characters, it is correctly written in database, but when doing either programmatic login or normal form based login, if fails.
If the password is only ascii, it works.
Username of login could be ascii or non-ascii, it doesn't matter, both works.
I'm using sun java application server 9.1.
jdbc realm.
I'm not using hashing passwords, just clean (now)
I tried configure realm Charset: UTF8 as last chance, but it doesn't work either.
The problem is only with non-ascii characters in password.
Any help very appreciated
Thanks a lot

hi,
I know all that, but that's not the case. My app uses preparedStatements, everything is properly configured, in all pages, utf-8 is going from user to db and back without any problems.
The only problem is with password field. As I am using form based login, with jdbc realm configured (again, nicely working when only ascii characters), I have very little chance to do something bad through the login phase.
I'm not talking about special characters, I'm talking about non-ascii characters, let's say - Chinese, arabish, Russian alphabet etc.
When user registers (my code), the fields are properly written to db. I have checked that, trust me.
But the Sun app server realm seems to have some problems with the password field.
(realm uses jdbc connection to mysql, the url contains all extra parameters to be sure about utf8. there is nothing more what can be configured...)
If I try other alphabet codes in login and ascii in password, it works. But soon, as I use other alphabet code also in password, it doesn't work anymore.
My only idea is, that I could try MD5 to create ascii only characters (I hope it works that way) on the client with javascript and then set Digest to MD5 in realm configuration. But still, it seems very strange. The clear way storage should also function? (now set Digest to 'none')
Is it a bug of Sun App Server?
thanks

Similar Messages

Problems with password including non-ASCII characters

I am a German language user with a German keyboard but an English OS as main language. Therefore my passwords (simple user and admin) includes non-ASCII characters used in German, French and Spanish language, which increases security. This works fine in the majority of login scenarios. There are, however, 3 scenarios where neither my non-ASCII simple user nor my non-ASCII admin PW are accepted:
1) running "sudo" in Terminal;
2) When I try to shut down and another user account is still open. Doing this brings up a login window asking for the PW of the other user that does not accept non-ASCII;
3) Using Leopard/SnowLeopard CacheCleaner. Upon opening, this app asks for an admin PW, but does not recognize non-ASCII.
Am I right in assuming that this has to do with non-ASCII PWs? I thought ASCII times were gone given the remarkable language flexibility of Mac OS over the years. I know this stupid problem only from Win XP. There it is even worse.
Is there a way to overcome this problem without always temporarily changing my PW? Thanks.

I think the problem is with the applications themselves and should be reported to the developer. Although some non-ASCII characters are acceptable for an admin password, in my experience most Unix systems don't like non-ASCII characters in passwords. It may be easier to avoid them if you can.
OS X should simply request your admin password to shut down when another user account is open. An alert dialog usually appears warning that the other user is still logged in and giving you the option to log the other account out then shut down. But in my experience the only authorization needed is for your admin account.

Does Oracle User Password can contain non-ASCII characters?

Hi Experts,
Can we create a user with password containing non-ASCII characters like "Ro'çá".
I was able to create a database instance by providing the password for sys as "Ro'çá". But now i am not able to login from command prompt using sqlplus or SQLPLUS Application. I am getting below error:
C:\Documents and Settings\xyz>sqlplus system/Ro'çá@test
SQL*Plus: Release 10.2.0.1.0 - Production on Sun Jul 4 12:17:33 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
ERROR:
ORA-12154: TNS:could not resolve the connect identifier specified
Enter user-name:
same in case i enclose the password in ""
C:\Documents and Settings\xyz>sqlplus system/"Ro'çá"@test
SQL*Plus: Release 10.2.0.1.0 - Production on Sun Jul 4 12:17:33 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
ERROR:
ORA-12154: TNS:could not resolve the connect identifier specified
Enter user-name:
same in case i enclose the password in ""
Also using create user i am not able to create user with password in non-ASCII characters but alter user works and changes the password to non-ASCII characters when enclosed in quotes.
I wanted to know whether the password can contain non-ASCII characters or not?
Thanks in advance for your help.

I don't think that the characters used are allowed. See this doc which only mentions three characters to be used .
http://download.oracle.com/docs/cd/E11882_01/server.112/e10575/tdpsg_user_accounts.htm#BEICECGF
I did try the same but it didn't work for me either.
SQL> select * from V$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> grant connect to user1 identified by Ro'çá;
ERROR:
ORA-01756: quoted string not properly terminated
SQL> grant connect to user1 identified by "Ro'çá";
Grant succeeded.
SQL> connect uesr1/"Ro'çá";
ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected to ORACLE.
SQL> connect uesr1/"Ro'çá"
ERROR:
ORA-01017: invalid username/password; logon denied
SQL> connect uesr1/"Ro'çá"
ERROR:
ORA-01017: invalid username/password; logon denied
SQL>HTH
Aman....

Problem with files containing non-English characters

I wrote a program that traverses a directory for files of a given extension and then displays the absolutePath in a JList. Double-clicking on a filename will open it in the registered program. It works perfectly for English filenames. The problem is when I have other characters in the filename. For example, if I have a file titled "Mexico.txt" with an accented e, it shows up in the list with a block in place of the e. So the first problem is not being able to properly display the special characters. Next, if I double-click that file it sees the absolutePath as "m%3Fxico.txt" which I'm guessing is some sort of unicode encoding. Unfortunately, that encoding is not handled properly by the Runtime.getRuntime() method. I get a "file does not exist" error. All features work fine with English characters.
Any help with these issues is greatly appreciated.

Send mail as text/html (HTML enabled content) , Specify charset in the header part (GB23... or UTF-8)of HTML
Its easy,
I hope it would solve ur problem
cheers
Rajendra Bandi

Cannot rename file with non-ASCII characters when using the

My application moves files from one directory to another by calling File[] srcFiles = srcDir.listFiles() to get a list of files in the source directory, and then calling srcFiles.renameTo(destFile) to rename each file.
This does not work (renameTo returns false and the file is not moved) under the following circumstances:
- the file's leaf name contains non-ASCII characters, for example "�"
- the OS is Solaris 9
- the LANG and LC_* environment variables are unset, i.e. the C locale is being used
If I set the LANG environment variable to, for example, en_GB.UTF-8 then the rename succeeds.
I have tried calling srcFiles[index].getName().getBytes("UTF-8") and the non-ASCII characters are being replaced with ? (0x3f) characters when LANG is unset.
Is this a bug in the JRE? I would argue that since my code does not actually manipulate the filename (I just use the File object that File.listFiles() gives me) then the rename should succeed. Of course I would not expect the file name to be displayed correctly if I printed it out.
I have reproduced this behaviour with JDK 1.4.2_05 and 1.5.0_04 on Solaris 9.
Francis

Thanks for the info Alan.
I considered setting the locale in the environment (this sounds like the "correct" fix to me and we might implement it later), but this application shares a WebLogic server with many other applications so we would have to do a huge amount of testing to make sure that the locale change wouldn't break the other apps. In the end I worked around the problem by making the code that generates the filenames in the first place strip out any non-ASCII characters (the names of the files are not critically important).
Looking forward to JSR-203, in the meantime perhaps a note about this behaviour in the java.io.File javadoc would be useful.

BUG: registered servers missing when password contains non-alphanumeric

I have a fresh installation of DS7 using Sun Java Web Server 7 to host DSCC7. Using DSCC7 web interface I click New Server and the procedure appears to complete successfully (no errors during creation, registration successful). However in the web interface the new server is not listed.
From the command line the new server is listed.
$ /opt/SUNWdsee7/bin/dsccreg list-servers
Hostname Port sPort Type Owner Flags iPath Description
www-c-directory 389 636 DS nobody /var/opt/SUNWdsee7/internal
Cause: the DSCC administrator's password contained non-alphanumeric characters (e.g. a left-angle bracket plus a few other punctuation characters) with about 10 characters in total.
Solution: from the web interface I navigated to Settings, Directory Service Managers, and changed the password for "admin" to a simpler password containing only alphanumeric characters.
Resolution: the registered servers now appear in the DSCC7 web interface as well as the command line. Oddly I can now return the password back to its original value and the servers still appear in the web interface.
Edited by: nhand42 on Jan 10, 2010 4:53 PM

English / C 7-bit ASCII.
The software has been installed inside a Whole Container, and the container was manually sysidcfg'd after the zone's installation (before the software installation) using zlogin -C.
Edited by: nhand42 on Jan 11, 2010 2:31 PM

Search for users and non-ASCII characters

I am having a little issue with the "Accounts - Find Users" functionality. The search breaks on what I assume is non-ASCII characters (we use the following three up here in Denmark: �, �, �). To be precise, I have a user with the first name "J�rgen". Searching for first names starting with "J" works just fine but "J�" returns zero matches.
My setup is with two machines, one (A) holding the MySQL database and one (B) serving Identity Manager on top of tomcat.
Both A and B are RHEL boxes, and both have da_DK.UTF-8 as default locale.
MySQL's /etc/my.cnf file has the following entry (as recommended in create_waveset_tables.mysql):
[mysqld]
default-character-set=utf8
default-collation=binFor clarity, some functionality works just fine in Identity Manager with these non-ASCII characters such as adding a user whose name contains non-ASCII characters (not only �� but also � for example). At the moment, it appears to be the search functionality which is not working correctly as I would expect it to. I'm still on the fence concerning whether I've missed something in terms of configuration, or whether this is a limitation.
Does anyone know whether this problem is on my side or the software's side?

I am having a little issue with the "Accounts - Find Users" functionality. The search breaks on what I assume is non-ASCII characters (we use the following three up here in Denmark: �, �, �). To be precise, I have a user with the first name "J�rgen". Searching for first names starting with "J" works just fine but "J�" returns zero matches.
My setup is with two machines, one (A) holding the MySQL database and one (B) serving Identity Manager on top of tomcat.
Both A and B are RHEL boxes, and both have da_DK.UTF-8 as default locale.
MySQL's /etc/my.cnf file has the following entry (as recommended in create_waveset_tables.mysql):
[mysqld]
default-character-set=utf8
default-collation=binFor clarity, some functionality works just fine in Identity Manager with these non-ASCII characters such as adding a user whose name contains non-ASCII characters (not only �� but also � for example). At the moment, it appears to be the search functionality which is not working correctly as I would expect it to. I'm still on the fence concerning whether I've missed something in terms of configuration, or whether this is a limitation.
Does anyone know whether this problem is on my side or the software's side?

CMSDK Non-ASCII Characters and WebFolders

Hi,
i have the follow problems with the CMSDK and Microsoft.
windows-explorer:
It is impossible to enter a folder that contains non-ascii characters in the name.(the clientrequest will never send.)
After the doubleclick on the foldername, i get a errormessage an then the url in the editbox is ISO-8859-1 encoded, but this url will never send to the sever.
Other operations like create, rename, ... have no problems with non-ascii chars.
with the IE, i can enter without a problem.
MS Word:
I can't save any file with non-ascii chars in the name.
Only this methods are send:
PROPFIND
PROPFIND
GET
GET
But never a "PUT", without a non-ascii char in the name the traffic looks like this:
PROPFIND
PROPFIND
GET
GET
PROPFIND
LOCK
PUT
It is also impossible to enter a folder containing non-ascii characters in the name, form the word filesave-dialog.
URL UTF-8 encoding is enabled in the IE options and other operations (MOVE,COPY) are send correctly UTF-8 encoded.
is there any solution?
thanks
Maik

Have you set the following DAV Server configuration property:
IFS.SERVER.PROTOCOL.DAV.Webfolders.DefaultCharset
for your domain?
You have to configure it for the character set that you want your clients to use when connecting to iFS via WebDAV.
(You can use the web admin tool to change this property.)
The reason for this is that the Microsoft WebFolders client software does not transmit the client's character set to the server, so the server has no way of knowing what to expect.

A Download servlet: non-ASCII characters not working

This is my servlet used for file download:
public void doPost(HttpServletRequest request, HttpServletResponse response) {
String filepath = request.getParameter("filepath");
String filename = request.getParameter("filename");
response.setContentType("application/zip");
response.setHeader("Content-Disposition", "attachment;filename=\""+filename+"\";");
ServletOutputStream sos = null;
BufferedInputStream bis = null;
try {
    sos = response.getOutputStream();
    bis = new BufferedInputStream(new FileInputStream(source));
    byte buffer[] = new byte[2048];
    int c;
    while((c = bis.read(buffer)) != -1)
      sos.write(buffer, 0, c);
} catch(Exception e) {
} finally {
    bis.close();
    sos.close();
}It does not work when the filename contains non-ASCII characters (e.g., extended ASCII, CJK ...)
What do I fix this? Thanks!

One possiblitiy that occurs to me is you have too many encoding things going on and you are sorta "over-encoding" things, as it were....
All I can think to do is give you this sample JSP page that I created when I was trying to figure all this web encoding stuff with forms back in the day. So perhaps you can use this as a basis for your own page.
// _lang.jsp
<%@ page language="java" contentType="text/html; charset=UTF-8" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
     <title></title>
     <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body bgcolor="#ffffff" background="" text="#000000" link="#ff0000" vlink="#800000" alink="#ff00ff">
<%
request.setCharacterEncoding("UTF-8");
String str = "\u7528\u6237\u540d";
String name = request.getParameter("name");
%>
req enc: <%= request.getCharacterEncoding() %><br />
rsp enc: <%= response.getCharacterEncoding() %><br />
str: <%= str %><br />
name: <%= name %><br />
<br />
<a href="_lang.jsp?name=<%= java.net.URLEncoder.encode(str, "UTF-8") %>">as link</a>
<br />
<br />
<form method="GET" action="_lang.jsp" encoding="UTF-8">
Name: <input type="text" name="name" value="" >
<input type="submit" name="submit" value="GET Submit" />
</form>
<form method="POST" action="_lang.jsp" encoding="UTF-8">
Name: <input type="text" name="name" value="" >
<input type="submit" name="submit" value="POST Submit" />
</form>
</body>
</html>

Non-ASCII Characters in AppleWorks

New to the forums and hope I'm not duplicating a prior post ... eons back, I used ClarisWorks on an old Mac SE/30, then moved over to AppleWorks which I got to use on my PC because I wanted to go back and work on something I had from years ago. The document in question contained non-ASCII characters. Anyway, I imported it into AppleWorks and what was once a Cyrillic font, was converted to ASCII (now a bunch of gibberish). I fully recognize I need to find the original font I used for the Cyrillic, but before I go that route, it looks like AppleWorks doesn't support non-ASCII characters ... ergo, I'm wasting my time. Am I wrong?
Thanks.
Windows 2.8 GHz Windows XP Pro

You may need to embed the font:
http://livedocs.adobe.com/flex/3/html/help.html?content=fonts_04.html
If this post answers your question or helps, please mark it as such.

Can Java be started in a directory that contains non ascii char

I installed a product developed using Java in a folder whose name contains non-ascii chars, such as Japanese chars or german chars.
This will cause error said: unable initialise java virtual machine, error code -1
Some one said Java doesn't like being started in a directory that contains non ascii characters. There appears to be no way of passing it unicode parameters.
Is there anyone once hit the similiar issue or know the root cause of such problem?
Thanks

Yes you can use your web start application console. To enter data which is required for your application it is better idea to use java application which runs in console mode althou you may try to run console of windows and then read data from its input stream.

Problems with non-ASCII characters on Linux Unit Test Import

I found a problem with non-ASCII characters in the Unit Test Import for Linux. This problem does not appear in the Unit Test Import for Windows.
I have attached a Unit Test export called PROC1.XML It tests a procedure that is included in another attachment called PROC1.txt. The unit test includes 2 implementations. Both implementations pass non-ASCII characters to the procedure and return them unchanged.
In Linux, the unit test import will change the non-ASCII characters in the XML file to xFFFD. If I copy/paste the the non-ASCII characters into the Unit Test after the import, they will be stored and executed correctly.
Amazon Ubuntu 3.13.0-45-generic / lubuntu-core
Oracle 11g Express Edition - AL32UTF8
SQL*Developer 4.0.3.16 Build MAIN-16.84
Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
In Windows, the unit test will import the non-ASCII characters unchanged from the XML file.
Windows 7 Home Premium, Service Pack 1
Oracle 11g Express Edition - AL32UTF8
SQL*Developer 4.0.3.16 Build MAIN-16.84
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
If SQL*Developer is coded the same between Windows and Linux, The JVM must be causing the problem.

Set the System property "mail.mime.decodeparameters" to "true" to enable the RFC 2231 support.
See the javadocs for the javax.mail.internet package for the list of properties.
Yes, the FAQ entry should contain those details as well.

Filling clob with non ascii characters

Hello,
I have had some problems with clobs and usage of german
umlauts (��). I was'nt able to insert or update
strings containing umlaute in combination with string
binding. After inserting or updating the umlaut
characters were replaced by strange (spanish) '?'
which were upside down.
However, it was working when I did not use string bindung.
I tried varios things, after some time I tracked
the problem down to to oracle.toplink.queryframework.SQLCall.java. In the
prepareStatement(...) you find something
like
ByteArrayInputStream inputStream = new ByteArrayInputStream(((String) parameter).getBytes());
// Binding starts with a 1 not 0.
statement.setAsciiStream(index + 1, inputStream,((String) parameter).getBytes().length);
I replaced the usage of ByteArrayInputStram with CharArrayReader:
// TH changed, 26.11.2003, Umlaut will not work with this.
CharArrayReader reader = new CharArrayReader(((String) parameter).toCharArray());
statement.setCharacterStream(index + 1, reader, ((String) parameter).length() );
and this worked.
Is there any other way achieving this? Did anyone
get clobs with non ascii characters to work?
Regards -- Tobias
(Toplink 9.0.3, Clob was mapped to String, Driver was Oracle OCI)

I don't think the console font is the problem. I use Lat2-Terminus16 because I read the Beginner's Guide on the wiki while installing the system.
My /etc/vconsole.conf:
KEYMAP=de
FONT=Lat2-Terminus16
showconsolefont even shows me the characters missing in the file names; e.g.: Ö, Ä, Ü

Replacing non-ASCII characters with HTML charcter references

Hi All,
In Oracle 10g or greater is there a built-in function that will convert a string with non-ASCII characters like this
a b č 뮼
into an ASCII string with HTML character references like this?
a b & # x 0 1 0 D ; & # x B B B C ;
(note I had to include spaces between each character in the sample code for message to prevent the forum software from converting my text)
I tried using
utl_i18n.escape_reference( val, 'us7ascii' )
but for some reason it returns
a b c & # x B B B C ;
Note how it converted the Western European character "č" to its unaccented counterpart "c", not "& # x 0 1 0 D ;" (is this a bug?).
I also tried a custom solution using regexp_replace and asciistr (which I can't include here because the forum software chokes on it) but it only returns the correct result for values <=4000 characters long. Unfortunately asciistr doesn't appear to accept CLOB values larger than 4000 characters. It returns an error message like
(ORA-22835: Buffer too small for CLOB to CHAR or BLOB to RAW conversion (actual: 30251, maximum: 4000) ).
I'm looking for a solution that works on CLOB data of any size.
Thanks in advance for any insight you can provide.
Joe Fuda

So with that (UTF8) in mind, let's take another look.....
As shown below, I used a AL32UTF8 database.
Note: I did not use a unicode capable tool for querying. So I set console mode code page to 1250 just to have č displayed properly (instead of posing as an è).
Also, as a result of using windows-1250 for client character set, in the val column and in the second select's ncr column (iso8859-1), è (00e8) has been replaced with e through character set conversion going from server back to client.
Running the same code on a database with a db character set such as we8mswin1252, that doesn't define the č (latin small c with caron) character, would yield results with a c in the ncr column.
C:\>chcp 1250
Aktuell teckentabell: 1250
C:\>set nls_lang=.ee8mswin1250
C:\>sqlplus test/test
SQL*Plus: Release 11.1.0.6.0 - Production on Fri May 23 21:25:29 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the OLAP option
SQL> select * from nls_database_parameters where parameter like '%CHARACTERSET';
PARAMETER              VALUE
NLS_CHARACTERSET       AL32UTF8
NLS_NCHAR_CHARACTERSET AL16UTF16
SQL> select unistr('\010d \00e8') val, utl_i18n.escape_reference(unistr('\010d \00e8'),'us7ascii') NCR from dual;
VAL NCR
č e c e
SQL> select unistr('\010d \00e8') val, utl_i18n.escape_reference(unistr('\010d \00e8'),'we8iso8859p1') NCR from dual;
VAL NCR
č e &# x10d; e     <- "è"
SQL> select unistr('\010d \00e8') val, utl_i18n.escape_reference(unistr('\010d \00e8'),'ee8iso8859p2') NCR from dual;
VAL NCR
č e č &# xe8;
SQL> select unistr('\010d \00e8') val, utl_i18n.escape_reference(unistr('\010d \00e8'),'cl8iso8859p5') NCR from dual;
VAL NCR
č e &# x10d; &# xe8;In the US7ASCII case, where it should be possible for all non-ascii characters to be escaped, it seems as if the actual escape step is skipped over.
Hope this helps to understand whether utl_i8n is usable or not in your case.
Message was edited by:
orafad
Fixed replaced character references :)

Problem with non-ASCII characters on TTY

Although I'm not a native speaker, I want my system language to be English (US), since that's what I'm used to. However I have a lot of files which have German language in their file names.
My /etc/locale.conf has en_US.UTF-8 and de_DE.UTF-8 enabled. My /etc/locale.conf contains only the line
LANG=en_US.UTF-8
The German file names show up fine within Dolphin and Konsole (ls -a). But they look weird on either of the TTYs (the "console" you get to by pressing e.g. ctrl+alt+F1). They have other characters like '>>' or the paragraph symbol where non-ASCII characters should be. Is it possible to fix this?

I don't think the console font is the problem. I use Lat2-Terminus16 because I read the Beginner's Guide on the wiki while installing the system.
My /etc/vconsole.conf:
KEYMAP=de
FONT=Lat2-Terminus16
showconsolefont even shows me the characters missing in the file names; e.g.: Ö, Ä, Ü

Cannot login with password containing non-ascii characters

Similar Messages

Maybe you are looking for