Databases
StackOverflow2013
Postsdbo
POBasic authentication encoding when credentials contain Unicode
Body
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POBasic authentication encoding when credentials contain Unicode
    text
    copied!<p>I have been banging my head against the wall on this problem. I've read similar posts &amp; articles; most suggest to set URIEncoding to UTF-8 in Tomcat's server.xml file, but that doesn't seem to make a difference here.</p> <p>I have a ReSTful web service deployed to a test environment where it is hosted on Tomcat 7. Tomcat is configured to use Java 6, although Java 7 is installed on the machine as well. When running basic authentication tests against the service hosted there, login fails and I receive a response of HTTP status 401 when the <em>original</em> credentials contain Unicode characters. Basic auth works fine when the credentials contain only ASCII. I can also login without using basic auth at all - my service supports custom login headers and RFC 2047. Using that approach, it doesn't matter whether the credentials contain Unicode or not, logging in is not a problem.</p> <p>Specifically the "problem" appears to be that the username is being UTF-8 encoded twice. There is a bug in my logger (separate issue) where the log files are ANSI-encoded. When you convert the log files to UTF-8, the characters will appear correctly. But in this case, the problematic username is much longer than it should be, and when the file is converted to UTF-8 it then appears like it should have in the first place (before being converted). For example:</p> <ul> <li>BAD (BASIC AUTH): SampleUser-¢𣎴eÌ‚é¾± -> SampleUser-¢𣎴eÌ‚é¾±</li> <li>GOOD (RFC 2047): SampleUser-¢𣎴eÌ‚é¾± -> SampleUser-¢ê龱</li> </ul> <p>The real kicker here is that I have my own instance of Tomcat 7 (Java 6) running locally, and I cannot reproduce the problem against it. I've compared the conf directories of the two Tomcats and they appear to be the same. I can't figure out why basic auth is working in one environment and not the other. I'm running the tests from my machine so it can't be due to a discrepancy in the way I'm testing it (JUnit/JSystem).</p> <p>Here's what I know:</p> <ul> <li>It doesn't matter what kind of user we're talking about with respect to privileges. Unicode in the username is the problematic factor.</li> <li>It doesn't matter whether the request is sent via XML or JSON. My service supports both types of serialization.</li> <li>The accept charset and content-type (if applicable) are both set to UTF-8 on the request.</li> <li>The Java system properties are the same in both environments.</li> </ul> <p>The following articles are very interesting to me, because they suggest the possibility of combining RFC 2047 and basic auth together. I didn't think that would be necessary because the basic auth string itself contains only ASCII (as it is base-64 encoded). Even if so, why would such a thing be required on one Tomcat server and not another? I feel like pursuing this combination approach isn't addressing the root problem, which is what's really driving me mad!</p> <ul> <li><a href="http://www.mentby.com/Group/tomcat-user/basic-authentication-failed-with-multibyte-username.html" rel="nofollow noreferrer">http://www.mentby.com/Group/tomcat-user/basic-authentication-failed-with-multibyte-username.html</a></li> <li><a href="https://stackoverflow.com/questions/7242316/what-encoding-should-i-use-for-http-basic-authentication">What encoding should I use for HTTP Basic Authentication?</a></li> </ul> <p>Thanks in advance for suggestions on things to try or double-check. The test environment is somewhat limited to me - I can only "play with it" during off-hours, so I apologize in advance if I don't respond promptly.</p>
 

Querying!

 
Guidance
An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload