ESAPI
New XML config and config management needed
From [email protected] on September 29, 2010 14:35:21
XML-Validation is a good thing but only part of the story. It would be cool if there was an additional test that checked the configuration for dependencies. For example if you have a reference to a class, it would check if the class exists and this before you launch the application server.
Another thing that would be cool would be to split HTTPUtilities. A quick look at the documentation shows that this interface is a case of excessive SRP* violation...
- The HTTPUtilities interface is a collection of methods that provide additional security related to HTTP requests,
- responses, sessions, cookies, headers, and logging.
-Sebastian Kübeck
- The Single Responsibility Principle is one of the oldest and most respected design principles... http://www.objectmentor.com/resources/articles/srp.pdf
Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=154
From [email protected] on November 02, 2010 00:52:10
I agree with this 100%. I'd like to do this before 2.0
Labels: Milestone-Release2.0
From [email protected] on November 02, 2010 00:53:50
and PS: Ignore the top section, please only consider the following for this bug:
Another thing that would be cool would be to split HTTPUtilities. A quick look at the documentation shows that this interface is a case of excessive SRP* violation...
- The HTTPUtilities interface is a collection of methods that provide additional security related to HTTP requests,
- responses, sessions, cookies, headers, and logging.
-Sebastian Kübeck
- The Single Responsibility Principle is one of the oldest and most respected design principles... http://www.objectmentor.com/resources/articles/srp.pdf
From [email protected] on November 06, 2010 20:57:41
This issue would then seem to be duplicated in issue #172 .
172 is tagged with a different milestone.
From [email protected] on November 18, 2010 18:37:02
This is different than 172, but I still bumped this milestone up to 2.1
Labels: -Milestone-Release2.0 Milestone-Release2.1
I am deferring this until ESAPI 3.0 and thus setting a milestone of 3.0. One cannot simply choose to remove public methods or to just move them to another class without likely breaking backward compatibility. When one is maintaining a general, reusable class library, one must take a much more reserved approach to refactoring public (and protected) methods. ESAPI 3.0 is expected to be a clean break from ESAPI 2.x with no promise of backward compatibility with previous ESAPI releases, therefore this is more appropriate for the 3.0 milestone.
