Мой проект работает на сервере разработки. Он работает в обоих следующих случаях:
- С каталогом .esapi в исходном пути, чтобы он попал в WEB-INF/classes
- С каталогом .esapi в корне библиотеки, чтобы он оказался в WEB-INF/lib
Однако он не работает при развертывании в Google (с использованием любой из двух вышеперечисленных стратегий).
Я получаю обычные сообщения о том, что не могу найти ESAPI. properties, когда я впервые пытаюсь использовать ESAPI после развертывания в Google.
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.
Обновление Проблема заключается в том, что строка 603 файла org.owasp.esapi.reference.DefaultSecurityConfiguration вызывает ClassLoader.getSystemClassLoader(), что недопустимо в Google Appengine. Это вызывает исключение выше (извините, оно обрезано). В массив предварительно загружаются три 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"
};
Я взломал свою собственную копию DefaultSecurityConfiguration, где я удалил SystemClassLoader (и соответствующее classLoaderName) из метода loadConfigurationFromClasspath.
ClassLoader[] loaders = new ClassLoader[] {
Thread.currentThread().getContextClassLoader(),
getClass().getClassLoader()
};
String[] classLoaderNames = {
"current thread context class loader",
"class loader for DefaultSecurityConfiguration class"
};
По иронии судьбы, именно потому, что они упростили чтение/расширение кода (ИМХО), зациклившись на загрузчиках классов, этот подход терпит неудачу. У меня возникает соблазн отправить патч с внутренним классом, чтобы отложить вызов getSystemClassLoader (чего нельзя сделать в AppEngine).
Интересно, что это работает так, как это возможно только потому, что банка esapi не запечатана. Я бы подумал, что банка с библиотекой безопасности должна быть запечатана. Может быть, я использую неправильный!
Обновление Я использую банку esapi через maven, она была переупакована и не подписана. Не идеально, но не менее безопасно, чем другие 40 банок с открытым исходным кодом, которые я получаю от maven!
