5

从 JBoss 4 升级到 JBoss 5 后，我注意到最烦人的回归。它会截断 base64 cookie 值的尾随等号 ('=')。

我花了很多时间才明白问题不是我的代码，而是 JBoss'，我用谷歌搜索了它，发现这是一个已知问题。

建议的解决方法是计算字符串长度并用尾随等号填充它（长度为 4 的重数）。

由于我们的应用程序可以在多个应用程序服务器（例如 WebLogic、WebSpehere）上运行，因此我非常不愿意为这个版本的 JBoss 添加这段代码。

有人遇到过这个吗？你能建议一个更聪明的解决方法吗？

编辑：感谢@skaffman，我理解了我的问题，我不应该首先使用 base64 作为 cookie 字符串。在 base 64 上有一个变体，称为base64 url ​​，应该用于此类字符串（cookies、urls...）。例如，库 Apache 编解码器在其 base 64 实现中支持此变体。

4

3 回答 3

6

您是否可以控制您的 cookie 的创建和编码/解码方式？如果是这样，那么您可以切换到另一种编码机制，该机制不使用可能与 cookie 规范冲突的字符。例如，Apache Commons Codec包含一个Hex类，该类可以将二进制数据编码和解码为十六进制字符串。它会大于 base64 中的等效数据，但这可能无关紧要。

或者，您可以稍微使用一下Cookie API。Cookie.setValue()的 javadoc说：

对于版本 0 cookie，值不应包含空格、方括号、圆括号、等号、逗号、双引号、斜杠、问号、at 符号、冒号和分号。空值在所有浏览器上的行为方式可能不同。

所以从技术上讲，base64 编码与版本 0 的 cookie 不兼容，这可能是默认设置。您可以尝试调用setVersion(1)cookie，看看是否会有所不同，尽管这样您会冒浏览器兼容性问题的风险。

于 2009-11-08T14:48:16.787 回答
1

如果我正确理解错误报告，编码器的正确实现将始终生成一个 4 的倍数的字符串，因此如果您添加错误修复，它不会在 JBoss 之外的其他应用程序服务器中触发。因此，您的代码将适用于所有服务器。附带说明一下，也许您可​​以将其实现为 servlet 过滤器，这对您的应用程序的干扰最小。

于 2009-11-07T14:28:52.323 回答
1

对于 jboss 5 设置以下系统属性：

org.apache.catalina.STRICT_SERVLET_COMPLIANCE=false

--巴拉

于 2010-02-11T23:57:22.347 回答