-
Notifications
You must be signed in to change notification settings - Fork 364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 2.2.1.1 Not Loading Properties in dependant JARs #567
Comments
Since the 2.2.1.0 release, the package name for JavaLogFactory has changed.
Details in the release notes.
…-kevin
--
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.
On Tue, Jul 28, 2020, 03:08 tntim96 ***@***.***> wrote:
After waiting for the fix for #560
<#560> , I upgraded from
2.2.0.0 to 2.2.1.1 and added the required properties so my tests pass
without error in the module, let's call it module A, which includes the
ESAP JAR dependency.
When running the tests in module B, which depends on module A, I get the
following errors (even though module A contains the necessary properties
files, and this wasn't an issue before the upgrade):
Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.ClassNotFoundException: org.owasp.esapi.reference.JavaLogFactory LogFactory class (org.owasp.esapi.reference.JavaLogFactory) must be in class path.
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:108)
at org.owasp.esapi.ESAPI.logFactory(ESAPI.java:139)
at org.owasp.esapi.ESAPI.getLogger(ESAPI.java:155)
at org.owasp.esapi.reference.DefaultEncoder.<init>(DefaultEncoder.java:83)
at org.owasp.esapi.reference.DefaultEncoder.getInstance(DefaultEncoder.java:67)
Caused by: java.lang.ClassNotFoundException: org.owasp.esapi.reference.JavaLogFactory
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.owasp.esapi.util.ObjFactory.loadClassByStringName(ObjFactory.java:158)
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:81)
The ESAPI.properties file works fine in module A with these contents:
ESAPI.printProperties=false
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
Encryptor.CipherTransformation=AES/CBC/PKCS5Padding
ESAPI.Logger=org.owasp.esapi.logging.java.JavaLogFactory
Logger.ApplicationName=MyAppName
Logger.LogEncodingRequired=false
Logger.LogApplicationName=true
Logger.LogServerIP=true
Logger.LogFileName=ESAPI.log
Logger.UserInfo=true
Logger.ClientInfo=true
Validator.ConfigurationFile=esapi-validation.properties
Validator.ConfigurationFile.MultiValued=false
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#567>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAO6PG3TITJ2UNN2WID2J4DR5Z2N7ANCNFSM4PKGM2SA>
.
|
@tntim96 - Specifically, you appear to still have Those details should all be in the 2.2.1.1 release notes. If this doesn't address this for you, let me know with a comment on this issue and I will reopen this and look into it deeper. |
Hi @kwwall
I've posted the contents of my
That class doesn't exist. It should be
I've already done that (otherwise the ESAPI tests in module A wouldn't have passed). |
I think I've found the problem in org/opensaml/ESAPISecurityConfig.java
|
Sigh. How does OpenSAML know that the application using it wants to use
that implementation anyway? Instead of returning a String,
getLogImplementation() should return the org.owasp.esapi.Logger
implementation by doing
return ESAPI.log();
That is,
public org.owasp.esapi.Logger getLogImplementation() {
return ESAPI.log();
}
They shouldn't be coding against implementations. I'd suggest writing a
issue against OpenSAML.
Of course, in hindsight, maybe we should have just deprecated these old
Logger classes and just changed them to wrappers that use the new package
names. However, I think that would be a little confusing (multiple class
names in 2 different packages), but it would have allowed more time for
things like this to surface. Of course given how common it is for
developers to just ignore deprecation warnings during compilation it
probably wouldn't have helped as much as it should.
…-kevin
--
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.
On Tue, Jul 28, 2020, 20:28 tntim96 ***@***.***> wrote:
I think I've found the problem in org/opensaml/ESAPISecurityConfig.java
public String getLogImplementation() {
return "org.owasp.esapi.reference.JavaLogFactory";
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#567 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAO6PGY2IYYHHYIJKWPZ4FTR55UKDANCNFSM4PKGM2SA>
.
|
@ArunenduRavi - The best thing to do -- assuming that the OpenSAML folks would accept it, I think the best approach would be to create a PR against OpenSAML to fix this on their side. Because without playing some really UGLY games with the class loader, I can't see how we can fix this in ESAPI. If they prefer to keep
(which is way more straight forward and ought to be what they are doing anyhow), you would have your PR do this instead:
Alternatively, instead of throwing a When you submit a PR for OpenSAML, you probably should also create a GitHub issue (or BugZilla or Jira or whatever bug tracking system they are using) and link to this issue so they know it was the ESAPI team that sent youthere. However, if they don't accept a PR, that's a bit harder to solve. If their jar is not sealed, you could pull out their affected class that has the Lastly, if you do create a GitHub issue for OpenSAML regarding this, please do return here and provide us a link to the issue you create so I can watch it and maybe comment on it. Hope that helps. -kevin |
After waiting for the fix for #560 , I upgraded from
2.2.0.0
to2.2.1.1
and added the required properties so my tests pass without error in the module, let's call it module A, which includes the ESAP JAR dependency.When running the tests in module B, which depends on module A, I get the following errors (even though module A contains the necessary properties files, and this wasn't an issue before the upgrade):
The
ESAPI.properties
file works fine in module A with these contents:The text was updated successfully, but these errors were encountered: