logSpecial assumes logging has not been manually set

[meg23]

From rob.spre...@gmail.com on November 12, 2009 17:17:08

What steps will reproduce the problem? 1. call ESAPI.setLogFactory to set a LogFactory Programmatically.
2. call ESAPI.securityConfiguration() What is the expected output? What do you see instead? I would expect the output from the constructor of
DefaultSecurityConfiguration to log according to whatever configuration my
factory provides. Instead, it should log using the factory if it has
already been configured. What version of the product are you using? On what operating system? Found in 1.4, confirmed in 2.0rc4 Please provide any additional information below. DefaultSecurityConfiguration probably shouldn't check to see if a factory
is set in the logSpecial method, because then we may get half logged to
System.out and half to a log file. A flag should be set in the
constructor, and then reset when getLogImplementation is called, or some
similar trigger.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=58

[meg23]

From rob.spre...@gmail.com on November 12, 2009 14:18:04

I'm fine with setting this to Low Priority, buy I'm not sure how.

[meg23]

From chrisisbeef on December 01, 2009 23:32:05

Changed to low priority and scheduled for 2.1

Status: Accepted
Labels: -Priority-Medium Priority-Low Milestone-Release2.1

[meg23]

From chrisisbeef on November 20, 2010 13:52:35

Labels: Component-Logger

[meg23]

From rob.spre...@gmail.com on July 19, 2011 06:56:44

This is still needed. Given the changes in 2.0 to the loading, the initial setup is no longer valid, as you can't set a logFactory any longe before loading the security configuration. The solution to this should also address that problem.

[meg23]

From r.nagesh...@gmail.com on May 02, 2014 13:39:02

why do we still see System.out.println instead of loggers. it would be good to use java.util.logging instead of using Sysouts, if you won't prefer slf4j/log4j.

something like this

use static variable
public class DefaultSecurityConfiguration implements SecurityConfiguration {
private static java.util.logging.Logger log = java.util.logging.Logger.getLogger(DefaultSecurityConfiguration.class.getName());
........
private void logSpecial(String message) {
log.log(Level.FINE, message);
}
....
}

[kwwall]

Related to GitHub issue #198. I'm not sure there is a viable solution for this because as explained in the referenced related issue, this is really a catch-22. One of the properties processed by the DefaultSecurityConfiguration class is ESAPI.Logger which can have various values. We could make a guess which one is set (let's say java.util.logging) only to discover once we have parsed ESAPI.Logger that it is really configured to use log4j or some other logger. What then, after we have already logged some of the output elsewhere?

I think the best workable scenario is allowing a configuration which simply allows the output from logSpecial() to be discarded. (It generally is only needed for initial debugging of ESAPI property configuration anyway.) To that end, if you run with the System property 'org.owasp.esapi.logSpecial.discard' set to the value "true", that will discard all output from logSpecial().

Unless someone has some ingenious idea, that probably is the best we are going to do.

[kwwall]

Punting this to the 3.0 milestone when we intend on completely rewriting this. I'm not sure there is a good solution until then (see #68 (comment)), or at least not without a complete rewrite of the SecurityConfiguration interface. There is at least a way to disable the logSpecial() output altogether so once you get it working as desired, you can make all the warnings that you all always ignore anyway just shut up and go away! :)