我的项目正在开发服务器上.它适用于以下两种情况：

>使用源路径中的.esapi目录,使其最终位于WEB-INF / classes中
>使用lib根目录中的.esapi目录,使其最终位于WEB-INF / lib中

但是,在部署到Google(使用上述两种策略之一)时,它不起作用.

我收到有关无法找到ESAPI的常见消息.我第一次尝试使用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的更改

更新
问题是org.owasp.esapi.reference.DefaultSecurityConfiguration的第603行调用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副本,我从loadConfigurationFromClasspath方法中删除了SystemClassLoader(和相应的classLoaderName).

    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.也许我用错了！

更新
我通过maven使用esapi jar,这已被重新包装并且没有签名.不理想,但它不比我从maven得到的其他40个开源罐子更安全！

解决方法:

使用自己的实现覆盖DefaultSecurityConfiguration类的解决方案正是解决问题的正确方法.这正是它以这种方式设计的原因.在Google App-Engine上使用ESAPI存在一些其他固有问题,主要是加密/散列问题.根据此主题(http://code.google.com/p/googleappengine/issues/detail?id=1612)上的评论,此问题已“部分”解决,但在GAE中使用加密仍存在严重限制.