Note that there are some explanatory texts on larger screens.

plurals
  1. POWhere does ESAPI.properties go in a Java Google AppEngine project
    primarykey
    data
    text
    <p>My project is working on the development server. It works in both the following cases:</p> <ol> <li>With the .esapi directory in the source path, so that it ends up in WEB-INF/classes</li> <li>With the .esapi directory in the lib root, so that it ends up in WEB-INF/lib</li> </ol> <p>However, it doesn't work when deployed to Google (using either of the above 2 strategies).</p> <p>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.</p> <pre><code>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 </code></pre> <p>ESAPI does appear to include changes to support AppEngine <a href="http://goo.gl/rD8dz" rel="nofollow">http://goo.gl/rD8dz</a></p> <p><strong>Update</strong> 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.</p> <pre><code> 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" }; </code></pre> <p>I've hacked in my own copy of DefaultSecurityConfiguration where I've removed the SystemClassLoader (and corresponding classLoaderName) from the loadConfigurationFromClasspath method.</p> <pre><code> ClassLoader[] loaders = new ClassLoader[] { Thread.currentThread().getContextClassLoader(), getClass().getClassLoader() }; String[] classLoaderNames = { "current thread context class loader", "class loader for DefaultSecurityConfiguration class" }; </code></pre> <p>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).</p> <p>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!</p> <p><strong>Update</strong> 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!</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload