Allow configurable init parameter in ESAPIFilter for unauthorized requests

[kwwall]

The ESAPIFilter currently has a hard-coded page ("WEB-INF/index.jsp") that users are forwarded to if they are not authorized for the current requested page. The logic is:

			// check access to this URL
			if ( !ESAPI.accessController().isAuthorizedForURL(request.getRequestURI()) ) {
				request.setAttribute("message", "Unauthorized" );
				RequestDispatcher dispatcher = request.getRequestDispatcher("WEB-INF/index.jsp");
				dispatcher.forward(request, response);
				return;
			}

The hard-coded "WEB-INF/index.jsp" should be replaced by an init parameter that can be set in the web.xml when this JavaEE servlet filter is configured, but this should remain the default for backwards compatibility.

I will name this new init parameter "publicUnauthorizedLandingPage" (the parameter name emphasizing that that landing page itself should be probably be accessible be everyone, or at least all authenticated users)

[jeremiahjstacey]

In the past we've discussed working to decouple from the singletons in the ESAPI baseline. The API here presents an opportunity to do that, I think.

The function javax.servlet.Filter.init(FilterConfig) appears to be the setup function for the Filter instance. From the FilterConfig reference we can allow the external webContainer to provide the unauthorized URL/Location for the environment. Similar to how the resourceDirectory is being used, if the value is not provided in the configuration then use the existing default of "WEB-INF/index.jsp".

Alternatively, the value could go into the properties and we could use Singletons to retrieve it from the ESAPI context. From previous discussions on the difficulty of refactoring those implementations I'm hesitant to suggest that route.

/** Redirect location for unauthorized access.*/
private String unauthRedirect = "WEB-INF/index.jsp";

public void init(FilterConfig filterConfig) {
		String path = filterConfig.getInitParameter("resourceDirectory");
		if ( path != null ) {
			ESAPI.securityConfiguration().setResourceDirectory( path );
		}
            
               String unAuthRedirectPath = filterConfig.getInitParameter("unauthRedirect");
               if (unAuthRedirectPath != null) {
                   //logger.info ("Configuring ESAPI Unauthorized Path from FilterConfig: ", unAuthRedirectPath );
                   unauthRedirect = unAuthRedirectPath;
              }
	}

Then reference the new class variable in place of the current hard-coded path.

RequestDispatcher dispatcher = request.getRequestDispatcher(unauthRedirect );

I believe this then requires that the end-user configure their environments to provide the filter with the needed information in order to override the default behavior and keeps the additional code and implementation scope for this correction limited to this class in ESAPI.

[kwwall]

@jeremiahjstacey Yes; that exactly was my point for creating this GitHub issue and what I intend to do (or, actually have already done; just haven't submitted the PR yet). @simon0117 was the one who pointed out that "WEB-INF/index.jsp" was hard-coded. I have configured it so that if a user doesn't configure it in their web.xml, that it will still default to the same old value.

[kwwall]

Close via PR #464