ESAPI.properties 在 Java Google AppEngine 项目中的位置

发布于 2025-01-07 23:05:51 字数 2324 浏览 4 评论 0原文

我的项目正在开发服务器上运行。它适用于以下两种情况:

  1. .esapi 目录位于源路径中,因此它最终位于 WEB-INF/classes
  2. .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:

  1. With the .esapi directory in the source path, so that it ends up in WEB-INF/classes
  2. 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

梦言归人 2025-01-14 23:05:51

使用您自己的实现重写 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.

一曲琵琶半遮面シ 2025-01-14 23:05:51

我刚刚在 Google App Engine 项目上成功集成了 ESAPI 2.1.0,而且我什至没有使用 Maven。

放置 ESAPI.properties & validation.properties 位于目录 [gae-project]/war/ESAPI/ 中。
因此,ESAPI.properties 的完整路径将

[gae-project]/war/ESAPI/ESAPI.properties

放在 war/ 下,以确保文件将上传到 Google。

编辑您的 appengine-web.xml,在 根节点中添加以下行,

...
<system-properties>
    <property name="java.util.logging.config.file" value="WEB-INF/logging.properties" />
    <property name="org.owasp.esapi.resources" value="ESAPI" />
</system-properties>
<static-files>
    <exclude path="/ESAPI**properties" />
</static-files>
...

以允许 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

[gae-project]/war/ESAPI/ESAPI.properties

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 node

...
<system-properties>
    <property name="java.util.logging.config.file" value="WEB-INF/logging.properties" />
    <property name="org.owasp.esapi.resources" value="ESAPI" />
</system-properties>
<static-files>
    <exclude path="/ESAPI**properties" />
</static-files>
...

that 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

苍景流年 2025-01-14 23:05:51

您可以将文件放在 META-INF/ 目录中,然后将 org.owasp.esapi.resources 系统属性更改为 META-INF/appengine-web.xml 中,如下所示:

    <system-properties>
      <property name="org.owasp.esapi.resources" value="META-INF/" />
    </system-properties>

因为 DefaultSecurityConfiguration 首先在资源目录中查找配置文件,然后在类路径中查找。

You can put the files in META-INF/ directory and then change the org.owasp.esapi.resources system property to META-INF/ in appengine-web.xml as follows:

    <system-properties>
      <property name="org.owasp.esapi.resources" value="META-INF/" />
    </system-properties>

Because DefaultSecurityConfiguration seeks configuration files first in the Resource Directory then in the classpath.

花之痕靓丽 2025-01-14 23:05:51

以下步骤对我有用。

  1. 解压 jar
  2. 创建一个文件夹 .esapi
  3. 下载 ESAPI.properties
  4. 创建 jar。
  5. 使用它,它不会再抱怨缺少属性文件了。

The following steps worked for me.

  1. Extract the jar
  2. create one folder .esapi
  3. download ESAPI.properties
  4. create the jar.
  5. Use it,it won't complain about missing properties file anymore.
鲸落 2025-01-14 23:05:51

在我们的项目中,该文件位于 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文