私のプロジェクトは開発サーバーで作業しています。次の両方の場合に機能します。
- ソース パスに .esapi ディレクトリがあるため、最終的に WEB-INF/classes になります。
- lib ルートに .esapi ディレクトリがあるため、最終的に WEB-INF/lib になります。
ただし、(上記の 2 つの戦略のいずれかを使用して) Google にデプロイすると機能しません。
ESAPI が見つからないという通常のメッセージが表示されます。Google にデプロイされた ESAPI を初めて使用しようとしたときのプロパティ ファイル。
Attempting to load ESAPI.properties via file I/O.
Attempting to load ESAPI.properties as resource file via file I/O.
Not found in 'org.owasp.esapi.resources' directory or file not readable: /base/data/home/ap
Not found in SystemResource Directory/resourceDirectory: .esapi/ESAPI.properties
Loading ESAPI.properties via file I/O failed. Exception was: java.io.FileNotFoundException
Attempting to load ESAPI.properties via the classpath.
ESAPI.properties could not be loaded by any means. Fail. Exception was: java.security.Acces
ESAPI には、AppEngine をサポートするための変更が含まれているようですhttp://goo.gl/rD8dz
更新 問題は、org.owasp.esapi.reference.DefaultSecurityConfiguration の 603 行目で、Google Appengine では違法な ClassLoader.getSystemClassLoader() を呼び出すことです。これにより、上記の例外が発生します (トリミングされて申し訳ありません)。コードがリソースを取得しようとする前に、3 つの ClassLoader が配列に読み込まれます。
ClassLoader[] loaders = new ClassLoader[] {
Thread.currentThread().getContextClassLoader(),
ClassLoader.getSystemClassLoader(),
getClass().getClassLoader()
};
String[] classLoaderNames = {
"current thread context class loader",
"system class loader",
"class loader for DefaultSecurityConfiguration class"
};
LoadConfigurationFromClasspath メソッドから SystemClassLoader (および対応する classLoaderName) を削除した DefaultSecurityConfiguration の独自のコピーをハッキングしました。
ClassLoader[] loaders = new ClassLoader[] {
Thread.currentThread().getContextClassLoader(),
getClass().getClassLoader()
};
String[] classLoaderNames = {
"current thread context class loader",
"class loader for DefaultSecurityConfiguration class"
};
皮肉なことに、このアプローチが失敗するのは、クラスローダーをループすることでコードを読みやすく/拡張しやすくしたためです (IMHO)。getSystemClassLoader の呼び出しを遅らせる内部クラスを含むパッチを提出したくなります (これは AppEngine では実行できません)。
esapi jar が密閉されていないためにのみ可能であるため、これが機能するのは興味深いことです。セキュリティ ライブラリ jar を封印する必要があると考えていました。多分私は間違ったものを使用しています！
更新 Maven経由でesapi jarを使用していますが、これは再パッケージ化されており、署名されていません。理想的ではありませんが、Maven から入手した他の 40 個のオープン ソース jar と同じくらい安全です。