rest - 凭据包含 Unicode 时的基本身份验证编码

Question

在这个问题上我一直在碰壁。我读过类似的帖子和文章；大多数人建议在 Tomcat 的 server.xml 文件中将 URIEncoding 设置为 UTF-8，但这似乎对这里没有影响。

我将 ReSTful Web 服务部署到托管在 Tomcat 7 上的测试环境中。Tomcat 配置为使用 Java 6，尽管计算机上也安装了 Java 7。当针对那里托管的服务运行基本身份验证测试时，登录失败并且当原始凭据包含 Unicode 字符时，我收到 HTTP 状态 401 的响应。当凭据仅包含 ASCII 时，基本身份验证工作正常。我也可以在根本不使用基本身份验证的情况下登录 - 我的服务支持自定义登录 header 和 RFC 2047。使用这种方法，凭据是否包含 Unicode 并不重要，登录不是问题。

具体来说，“问题”似乎是用户名被 UTF-8 编码了两次。我的记录器中有一个错误(单独的问题)，其中日志文件是 ANSI 编码的。当您将日志文件转换为 UTF-8 时，字符将正确显示。但在这种情况下，有问题的用户名比它应该的长得多，当文件被转换为 UTF-8 时，它看起来就像它应该在第一位(在转换之前)。例如:

• 错误(基本授权):SampleUser-Ã,¢ð£Å½Â´eÌ‚é¾± -> SampleUser-¢𣎴eÌ‚é¾±
• 良好 (RFC 2047):SampleUser-¢𣎴eÌ‚é¾± -> SampleUser-¢𣎴ê龱

这里真正的问题是我有自己的 Tomcat 7 (Java 6) 实例在本地运行，我无法重现针对它的问题。我比较了两个 Tomcat 的 conf 目录，它们看起来是一样的。我不明白为什么基本身份验证在一个环境中工作而不在另一个环境中工作。我正在从我的机器上运行测试，所以这不可能是因为我测试它的方式 (JUnit/JSystem) 存在差异。

这是我知道的:

• 我们尊重的是哪种用户并不重要到特权。用户名中的 Unicode 是问题因素。
• 请求是通过 XML 还是 JSON 发送并不重要。我的服务支持这两种类型的序列化。
• 接受字符集和内容类型(如果适用)均根据请求设置为 UTF-8。
• Java 系统属性在两种环境中是相同的。

以下文章对我来说非常有趣，因为它们提出了将 RFC 2047 和基本身份验证结合在一起的可能性。我不认为这是必要的，因为基本的 auth 字符串本身只包含 ASCII(因为它是 base-64 编码的)。即使是这样，为什么一台 Tomcat 服务器需要这样的东西而不是另一台呢？我觉得采用这种组合方法并不能解决根本问题，这才是真正让我发疯的原因!

• > http://www.mentby.com/Group/tomcat-user/basic-authentication-failed-with-multibyte-username.html
• > What encoding should I use for HTTP Basic Authentication?

在此先感谢您对要尝试或仔细检查的事情提出建议。测试环境对我来说有些局限——我只能在下类时间“玩玩”，所以如果我没有及时回复，我提前道歉。

Answer 1

从您提供的数据来看，UTF-8 数据实际上似乎正在转换为 ASCII 编码，而不是双重 UTF-8 编码。

就实际问题而言，不幸的是，基本身份验证不提供任何方式来传输未解码的用户名和密码的字符集。因此，您的主要选择是假设并手动指定一个字符集，使用您环境中的默认字符集，或确定提供字符集的自定义方式(例如另一个 header )。每个选项都取决于您对环境和通信的客户端/服务器端的控制程度，以及您是否希望所有调用都使用相同的字符集。

基于一台服务器正常运行而另一台服务器运行不正常，我假设解码当前正在使用环境中的默认字符集。您是正确的，编码字符串将仅包含 ASCII(因此您可能没有看到传输编码值的问题)，因此数据可能在解码过程中(或之后)丢失。根据您选择的库，它可能会生成一个字节数组或一个字符串，因此请务必在从字节数组创建字符串时检查您是否提供了字符集(例如 new String(decodedData, someCharset))或看看是否有办法将它提供给库(如果它生成一个字符串)。