You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Activity
meg23 commentedon Nov 13, 2014
From manico.james@gmail.com 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
meg23 commentedon Nov 13, 2014
From manico.james@gmail.com 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...
-Sebastian Kübeck
of the oldest and most respected design principles... http://www.objectmentor.com/resources/articles/srp.pdf
meg23 commentedon Nov 13, 2014
From brent.sh...@gmail.com 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.
meg23 commentedon Nov 13, 2014
From manico.james@gmail.com 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
meg23 commentedon Nov 13, 2014
From manico.james@gmail.com on November 18, 2010 18:37:21
Labels: Configuration
meg23 commentedon Nov 13, 2014
From manico.james@gmail.com on May 28, 2012 20:24:22
Owner: chrisisbeef
kwwall commentedon Jul 5, 2019
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.