ESAPI.properties 在 Java Google AppEngine 项目中的位置
我的项目正在开发服务器上运行。它适用于以下两种情况:
- .esapi 目录位于源路径中,因此它最终位于 WEB-INF/classes
- .esapi 目录位于 lib 根目录中,因此它最终位于 WEB-INF/lib 中
但是,当部署到 Google 时(使用上述 2 种策略之一),它不起作用。
我经常收到有关无法找到 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 行调用 ClassLoader.getSystemClassLoader(),这在 Google Appengine 中是非法的。这会导致上面的异常(抱歉它被裁剪了)。 在代码尝试获取资源之前,会预先将三个类加载器加载到数组中。
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 副本,其中我从 loadConfigurationFromClasspath 方法中删除了 SystemClassLoader (和相应的 classLoaderName)。
ClassLoader[] loaders = new ClassLoader[] {
Thread.currentThread().getContextClassLoader(),
getClass().getClassLoader()
};
String[] classLoaderNames = {
"current thread context class loader",
"class loader for DefaultSecurityConfiguration class"
};
讽刺的是,正是因为他们通过循环类加载器使代码易于阅读/扩展(恕我直言),所以这种方法失败了。我很想提交一个带有内部类的补丁来延迟对 getSystemClassLoader 的调用(在 AppEngine 上无法做到这一点)。
有趣的是,这之所以有效,是因为 esapi jar 没有密封。 我本以为安全库罐子应该被密封。也许我用错了!
更新 我通过maven使用esapi jar,它已经被重新打包并且没有签名。不太理想,但它的安全性并不比我从 Maven 获得的其他 40 个开源 jar 差!
My project is working on the development server. It works in both the following cases:
- With the .esapi directory in the source path, so that it ends up in WEB-INF/classes
- With the .esapi directory in the lib root, so that it ends up in WEB-INF/lib
However, it doesn't work when deployed to Google (using either of the above 2 strategies).
I get usual messages about not being able to find the ESAPI. properties file when I first try to use ESAPI once deployed to 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 does appear to include changes to support AppEngine http://goo.gl/rD8dz
Update
The issue is that line 603 of org.owasp.esapi.reference.DefaultSecurityConfiguration calls ClassLoader.getSystemClassLoader() which is illegal in Google Appengine. This causes the exception above (sorry it's cropped).
There are three ClassLoaders loaded into an array upfront, before the code tries to get the resources.
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"
};
I've hacked in my own copy of DefaultSecurityConfiguration where I've removed the SystemClassLoader (and corresponding classLoaderName) from the loadConfigurationFromClasspath method.
ClassLoader[] loaders = new ClassLoader[] {
Thread.currentThread().getContextClassLoader(),
getClass().getClassLoader()
};
String[] classLoaderNames = {
"current thread context class loader",
"class loader for DefaultSecurityConfiguration class"
};
Ironically it's because they've made the code easy to read/extent (IMHO) by looping through Classloaders that this approach fails. I'm tempted to submit a patch with an inner class to delay the call to getSystemClassLoader (which you can't do on AppEngine).
It's interesting that this works as it's only possible because the esapi jar is not sealed.
I'd have thought a security library jar should be sealed. Maybe I'm using the wrong one!
Update
I'm using the esapi jar via maven, this has been repackaged and isn't signed. Not ideal, but it's no less secure than the other 40 open source jars I'm getting from maven!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
使用您自己的实现重写 DefaultSecurityConfiguration 类的解决方案正是解决问题的正确方法。这正是它如此设计的原因。不过,在 Google App-Engine 上使用 ESAPI 还存在一些其他固有问题,主要与加密/散列有关。根据此线程 (http://code.google.com/p/googleappengine/issues/detail?id=1612) 上的评论,此问题已“部分”解决,但在 GAE 中使用加密仍然存在严重限制。
Your solution of overriding the DefaultSecurityConfiguration class with your own implementation is precisely the correct way to address the problem. This is precisely the reason that it is designed this way. There are some other inherent problems with using ESAPI on Google App-Engine tho, primarily with regards to encryption/hashing. This issue has been "partially" resolved according to comments on this thread (http://code.google.com/p/googleappengine/issues/detail?id=1612) but there are still serious limitation on using encryption in GAE.
我刚刚在 Google App Engine 项目上成功集成了 ESAPI 2.1.0,而且我什至没有使用 Maven。
放置 ESAPI.properties & validation.properties 位于目录
[gae-project]/war/ESAPI/
中。因此,ESAPI.properties 的完整路径将
放在 war/ 下,以确保文件将上传到 Google。
编辑您的 appengine-web.xml,在
根节点中添加以下行,以允许 App Engine将 .properties 文件识别为项目文件。
有关更详细的讨论,您还可以阅读 Google App Engine 集成 ESAPI 教程
I just successfully integrated ESAPI 2.1.0 on a Google App Engine Project and I did not even use Maven for it.
Put the ESAPI.properties & validation.properties in the directory
[gae-project]/war/ESAPI/
.Thus, the full path of the ESAPI.properties will be
Putting it under the war/ ensures that the files will be uploaded to Google.
Edit your appengine-web.xml, add the following lines inside the
<appengine-web-app>
root nodethat will allow App Engine to recognize .properties files as project files.
for a more detailed discussion you can also read ESAPI for Google App Engine Integration Tutorial
您可以将文件放在
META-INF/
目录中,然后将org.owasp.esapi.resources
系统属性更改为META-INF/
在 appengine-web.xml 中,如下所示:因为
DefaultSecurityConfiguration
首先在资源目录中查找配置文件,然后在类路径中查找。You can put the files in
META-INF/
directory and then change theorg.owasp.esapi.resources
system property toMETA-INF/
in appengine-web.xml as follows:Because
DefaultSecurityConfiguration
seeks configuration files first in the Resource Directory then in the classpath.以下步骤对我有用。
The following steps worked for me.
在我们的项目中,该文件位于 WEB-INF/classes 文件夹中。我们不使用 .esapi 子文件夹。
Esapi version=2.0.1
不过部署在jboss中。
In our project the file resides in the WEB-INF/classes folder. We do not use a .esapi sub-folder.
Esapi version=2.0.1
Deployed in jboss though.