JBoss 5截断base64 = base64 cookie字符串

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

我花了很多时间才明白问题不是我的代码而是JBoss’,我用Google搜索并发现它是一个已知问题 。

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

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

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

编辑:感谢@skaffman我理解我的问题,我不应该首先使用base64 for cookie string。 base 64上有一个名为base64 url的变种,应该用于这样的字符串(cookies,urls ……)。 例如,Apache编解码器库在其基本64实现中支持此变体。

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

或者,您可以使用Cookie API。 Cookie.setValue()的javadoc说:

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

因此从技术上讲,base64编码与版本0 cookie不兼容,这可能是默认值。 您可以尝试在cookie上调用setVersion(1) ,看看是否会产生影响,尽管这样会冒浏览器兼容性问题。

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

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

org.apache.catalina.STRICT_SERVLET_COMPLIANCE = FALSE

–bala