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 回答