GoogleCodeExporter
commented
9 years ago This test was replaced with testConcurrency() in EncoderTest. Original comment by chrisisbeef on 2 Dec 2009 at 7:39
- Changed state: WontFix
Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago This test was replaced with testConcurrency() in EncoderTest. Original comment by chrisisbeef on 2 Dec 2009 at 7:39
GoogleCodeExporter
commented
9 years ago I don't agree with the "WontFix" status. We should either delete the test or
minimally use the Junit 4 '@Ignore' annotation before the test case so that the
test is
not executed. However, I think either approach is an acceptable "fix" if you
will.Original comment by kevin.w.wall@gmail.com on 3 Dec 2009 at 1:39
GoogleCodeExporter
commented
9 years ago The issue seems to occur with my application too. I'm using DefaultEncoder
class to encode javascript in the tag
class which would output the result on the jsp. I'm seeing the exact same
exception (java.lang.Exceptio
nInInitializerError) and stack trace. I tried using JavaScriptCodec directly
and it works just fine.
Is this a known issue? This issue never occurred with older version of the jar.
Please help. Thank you.Original comment by lake...@gmail.com on 7 Dec 2009 at 3:50
GoogleCodeExporter
commented
9 years ago Can you attach a code sample of how you are using the encoder?Original comment by chrisisbeef on 7 Dec 2009 at 4:30
GoogleCodeExporter
commented
9 years ago Unfortunately, I can't provide the actual code due to licensing reasons. But,
I'm
just instantiating DefaultEncoder object much like in the test case and calling
encodeForJavaScript method on it.
StringBuffer output = new StringBuffer();
Encoder encoder = new DefaultEncoder();
....
....
output.append(encoder.encodeForJavaScript("some text"));Original comment by lake...@gmail.com on 8 Dec 2009 at 1:47
GoogleCodeExporter
commented
9 years ago Here's a small simple test I just wrote...hope this helps.
import org.owasp.esapi.Encoder;
import org.owasp.esapi.reference.DefaultEncoder;
public class SimpleEncoderTest {
public static void main(String[] args) {
String text = "My funds @ St. Paul's Bank";
Encoder encoder = new DefaultEncoder();
System.out.println(encoder.encodeForJavaScript(text));
}
}
Here's the output when I run it with ESAPI-2.0-rc4.zip
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.owasp.esapi.reference.DefaultEncoder.<init>(DefaultEncoder.java:6
0)
at SimpleEncoderTest.main(SimpleEncoderTest.java:9)
Caused by: java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Properties.java:365)
at java.util.Properties.load(Properties.java:293)
at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadProperties
FromStream(DefaultSecurityConfiguration.java:370)
at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfigurat
ion(DefaultSecurityConfiguration.java:507)
at org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>(Default
SecurityConfiguration.java:207)
at org.owasp.esapi.ESAPI.<clinit>(ESAPI.java:87)
... 2 more
Here's the output when I run it with earlier version of the jar -
ESAPI-2.0rc2.jar(which doesn't exist on the downloads section anymore, I
downloaded
it when it was available)
My\x20funds\x20\x40\x20St.\x20Paul\x27s\x20Bank
Original comment by lake...@gmail.com on 8 Dec 2009 at 2:23
GoogleCodeExporter
commented
9 years ago This looks like the ESAPI.properties file can't be found on the classpath.Original comment by planetlevel on 8 Dec 2009 at 3:47
GoogleCodeExporter
commented
9 years ago Beat me to the punch here.
The problem here is the following line:
private final Logger logger = ESAPI.getLogger("Encoder");
This requires that ESAPI.properties be loadable from the classpath. Please also
note
that the ESAPI.properties file is no longer archived inside of the jar, the
distribution comes with the "default" ESAPI.properties in the
configuration/.esapi
directory.
This exception is not an issue with the code itself, but perhaps this is a
documentation issue?Original comment by chrisisbeef on 8 Dec 2009 at 5:19
GoogleCodeExporter
commented
9 years ago At a minimum, we need a better error message. If possible, should we deploy
with a
minimal default safe ESAPI.properties inside the jar? Or should we make it
operate
without an ESAPI.properties if none of the functions called really require it?Original comment by planetlevel on 8 Dec 2009 at 1:56
GoogleCodeExporter
commented
9 years ago I think allowing the ESAPI to be used in an *un-initialized* state creates a
couple
of problems, namely a significant amount of "defensive-code" spread throughout
the
codebase to account for the ability of the ESAPI to be in an uninitialized
state.
I can definately look into the error messaging for this case. Changing the
logger to
be initialized in a static block with a try...catch... should allow us to alter
the
error messaging such that it will be clearer what the problem is.
I am not sure if this will make it into the 2.0-final release at this point.
This
seems like a pretty low-priority issue compared to some of the other last minute
things that need to be dealt with. This is also something that can be fixed as
part
of a minor or patch release.
This should be scheduled for 2.0.2 or a later patch revisionOriginal comment by chrisisbeef on 8 Dec 2009 at 10:52
GoogleCodeExporter
commented
9 years ago Thanks for all the info guys. I agree with @planetlevel that it'd be convenient
if
ESAPI.properties can be bundled with jar.
With that said, how/where do I include this properties file to run this
successfully?
I'd appreciate it if you can explain the steps.
Also, what's the target date for final 2.0 release?
Thank you again for all your help. Original comment by lake...@gmail.com on 9 Dec 2009 at 2:09
GoogleCodeExporter
commented
9 years ago Originally we included the "default" ESAPI.properties in the jar, but we
removed it
from the jar and instead included it in the distribution ZIP.
@lakers8 (love the twitterification of the internet) - here are some links:
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/refe
rence/DefaultSecurityConfiguration.html
Also, the latest RC can be downloaded which includes documentation and
installation
instructions:
http://code.google.com/p/owasp-esapi-java/downloads/list
Original comment by chrisisbeef on 9 Dec 2009 at 4:14
GoogleCodeExporter
commented
9 years ago Two things to note. One it was decided not to include a default
ESAPI.properties file
in the ESAPI jar because (among other reasons), this no longer made sense when
we
stopped shipping ESAPI.properties file with default values for
Encryptor.MasterKey
and Encryptor.MasterSalt.
Secondly, has anyone ever checked this since Jim rewrote how the
ESAPI.properties
file is found in DefaultSecurityConfiguration? It may still be blowing up with
an
ExceptioninInIntializerError, but we should at least be getting something
logged.
Since one would see that this problem could happen for almost any reference
model
class if ESAPI.properties can't be found (since almost all of them try to
create a
Logger outside of any sort of try / catch block) if an object of an reference
implementation class is created like in the example code in Comment 6 by
lakers8, we
should really encourage people not to create classes in this manner. I'm pretty
sure
(but have not tried it) that creating an Encoder object via
Encoder encoder = ESAPI.encoder();
rather than via
Encoder encoder = new DefaultEncoder();
will shown a more reasonable Exception if we slightly tweak
ObjectFactory<T>.make()
so that it catches (at least) ExceptionInInitializerError. It would then
rethrow this
as an ConfigurationException (which is what it truly is) [note:
ConfigurationException is an unchecked exception] with
ExceptionInInitializerError
associated as the 'cause'. That would be a very simple addition, but if would
do
nothing for cases where people are directly initializing things via the
reference
model CTORs as was shown in laker8's sample code. Hence it should also include a
documentation note somewhere in the ESAPI Developer's Guide.Original comment by kevin.w.wall@gmail.com on 9 May 2010 at 2:20
GoogleCodeExporter
commented
9 years ago Interesting observation folks. I tested this w/out setting ESAPI.properties and
it
works fine. It seems like all the exceptions are being swallowed, just logging
them.
I'm using 1.4.4 version and I'm not using any ESAPI.properties(not even a blank
file,
file DOES NOT exist) and not seeing any exceptions! Can you guys confirm?Original comment by lake...@gmail.com on 26 May 2010 at 12:17
GoogleCodeExporter
commented
9 years ago Ping. Thoughs on this?Original comment by manico.james@gmail.com on 1 Nov 2010 at 6:05
GoogleCodeExporter
commented
9 years ago If exceptions are indeed being swallowed - this is no bueno. ESAPI should *not*
be allowed to execute code paths in an unconfigured state. I will try to look
into it this week. Original comment by chrisisbeef on 1 Nov 2010 at 7:11
GoogleCodeExporter
commented
9 years ago Chris, have you had a chance to look at this?
Meanwhile, since it is rated as a low priority, I am changing it to the 2.1
milestone.Original comment by kevin.w.wall@gmail.com on 12 Feb 2011 at 8:35
GoogleCodeExporter
commented
9 years ago Original comment by kevin.w.wall@gmail.com on 23 Sep 2014 at 1:44
Original issue reported on code.google.com by
lake...@gmail.comon 24 Nov 2009 at 2:07