JBoss 5は、base64クッキー文字列の末尾を切り捨てます

Question

JBoss 4からJBoss 5にアップグレードした後、私は最も面倒な回帰に気付きました。これは、base64のクッキー値の末尾にある等号（ '='）を切り捨てます。

問題は私のコードではなくJBossのものであることを理解するためには時間がかかりました。私はそれをgoogledして、それが知られていることを知りましたissueです。

回避策は、文字列の長さを計算し、後ろに等号（4の長さの長さ）で埋めてください。

私たちのアプリケーションは、いくつかのアプリケーションサーバー（WebLogic、WebSpehereなど）上で動作できるため、このバージョンのJBossに固有のこのコードを追加することは非常に嫌です。

誰かがこれに遭遇しましたか？よりスマートな回避策を提案できますか？

編集： @skaffmanのおかげで私は自分の問題を理解しました。最初はクッキー文字列にbase64を使用してはいけません。このような文字列（クッキー、URLなど）に使用されるbase64 urlという名前のベース64のバリアントがあります。たとえば、Apache Apacheコーデックライブラリは、ベース64実装でこの変種をサポートしています。

Answer 1

クッキーの作成方法とエンコード/デコード方法を制御できますか？そうであれば、代替のコード化メカニズムに切り替えることができます。これは、Cookie仕様と衝突するかもしれない文字を使用しないものです。たとえば、Apache Commons Codecには、バイナリデータを16進文字列にエンコードおよびデコードすることができるHexクラスが含まれています。それはbase64の同等のデータよりも大きいでしょうが、それは問題ではないかもしれません。

また、Cookie APIを使用してプレイすることもできます。 Cookie.setValue()が言うのJavadoc：バージョン0のクッキーで

を、値が ホワイトスペース、括弧、 括弧、を含めるべきではありませんが看板、カンマ、 二重引用符を、等しく、看板の質問 マークを、スラッシュ、コロン、および セミコロン。空の値では、すべてのブラウザで同じように動作しない可能性があります（ ）。

技術的には、base64エンコーディングはバージョン0のCookieと互換性がありません。これはデフォルトの可能性があります。クッキーにsetVersion(1)を呼び出そうとすると、違いがあるかどうかを確認できますが、ブラウザの互換性の問題が発生する可能性があります。 JBossの5のための

Answer 2

私がバグレポートを正しく理解している場合、エンコーダの正しい実装では常に4の倍数の文字列が生成されるため、バグ修正を追加するとJBoss以外のアプリケーションサーバーでトリガされません。あなたのコードはすべてのサーバで動作します。副次的には、サーブレットフィルタとして実装することができます。これは、アプリにとっては最小限の介入となります。

Answer 3

は、以下のシステムプロパティを設定します。

org.apache.catalina.STRICT_SERVLET_COMPLIANCE = falseを

--bala