Dependency on HttpServletRequest

[meg23]

From alanaca...@gmail.com on July 22, 2011 15:43:52

Hi

ESAPI Validation is dependent on HttpServletRequest. This might be fine when running in a servlet container, but not for unit tests.

Our application is split into three different projects, a thin web layer, business logic and finally database/ldap access. All of the managers live in the business layer, that have no knowledge of the web layer. This is where I would like the validation to occur.

When the business layer makes a call to ESAPI.validation() while running as unit tests, I get the following exception:
java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletRequest
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
at java.lang.Class.getMethod(Class.java:1603)
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:77)
at org.owasp.esapi.ESAPI.validator(ESAPI.java:191)

The servlet-api jar is already a part of my web project. I am not going to add it to the business layer project. Also, because of legacy issues, validation has to happen in the business layer.

I can bypass this exception by calling DefaultValidator.getInstance() directly. However, once it tries to log an XSS string in the unit test, I am back to the NoClassDefFoundError.

It would be nice if there was a way to turn off any dependency on the servlet container classes for unit testing.

Thanks,
Alana

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

[jyeary]

We have a similar issue. We are using Apache Mina for an application, and this has come up for us as an issue in the same manner.

[kwwall]

Breaking this dependency of HttpServletRequest out of Validator is going to be difficult without breaking backward compatibility. At this point, which you may not like it, your best approach is to either include the servlet-api jar in your classpath or create a special jar that just stubs out HttpServletRequest if you find that approach to heavy-weight. This is more of a re-architecture thing. I think that there has always been an implicit assumption that ESAPI would be used in the context of a JavaEE application server. That has both served it well as well as being a significant downside (e.g., in addition to the edge cases mentioned in this issue, it also limits ESAPI's usefulness in Android apps).

My strong preference at this point in time--unless someone does the work and makes it available as a PR--is to defer this sort of re-architecture issue until ESAPI 3.0. However, we will consider a well structured PR that will not break backward compatibility of existing code. But since there is a workaround for this, I'm bumping this down to a low priority.