Extraneous inclusion of logger in Base64Codec.php prevents overloading ESAPI

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Copy ESAPI.php to own file
2. Attempt to include custom file and use

What is the expected output? What do you see instead?
Expect to be able to extend ESAPI class to customize functionality.

What version of the product are you using? On what operating system?
Latest; on linux

Please provide any additional information below.
Base64Codec.php requires ESAPI.php specifically for what appears to be no other 
purpose than to create a Auditor instance local to the constructor (not even as 
a property of the new object).  The $logger variable created is not used.  
Removing this extraneous logger makes extending the ESAPI framework possible.

Original issue reported on code.google.com by esk...@gmail.com on 21 Sep 2010 at 2:11

[GoogleCodeExporter]

Hi!

I cannot think of a need to bring custom code into ESAPI class. This class 
simply provides factory methods for security controls. It does not contain or 
is supposed to contain any "magic".
You are encouraged to write adapters for security controls that fit your needs 
which is working out of the box.


Some background on ESAPI for PHP: This is an explicit port of ESAPI for Java 
into PHP world and there you find also the inclusion and *use of the logger* in 
the Base64 codec.
@see 
http://code.google.com/p/owasp-esapi-java/source/browse/branches/1.4/src/main/ja
va/org/owasp/esapi/codecs/Base64.java

In ESAPI for PHP the logger is currently not used but this might change in 
future.

Original comment by marcus.k...@googlemail.com on 22 Sep 2010 at 7:34

[GoogleCodeExporter]

Hi there,

I don't intend for ESAPI.php to be overridden like that. We're using factories 
to create the non-static classes, so I'd like for you to consider writing new 
or overriding the reference implementation, and instantiating that. ESAPI.php 
is a short cut to getting all the necessary code in place. 

Decoupling features is an interesting issue, as realistically, I think we 
should be saying the Logger and IDS and Exception classes will always be 
included by any class as they are a way of ensuring consistent ESAPI behavior 
and code re-use. 

However, I do know that over riding the ESAPI base / reference classes has 
never been done before in a real non-test app, so I will check that this 
actually works before we release 1.0. 

Original comment by vande...@gmail.com on 17 Jun 2011 at 3:34

• Added labels: Maintainability, Milestone-Release1.0

[GoogleCodeExporter]

All these issues must be dealt with before 1.0. New issues will be on a case by 
case basis as to whether we hold up 1.0 or not. 

Original comment by vande...@gmail.com on 17 Jun 2011 at 3:36