You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by je...@amd.com on 2002/01/16 00:58:37 UTC

TC4.01: Customized Valve disarmed security constraint

Hi, there,

I created a customized Valve by extending AuthenticatorBase for purpose of opening a backdoor to my application. It failters request and create a user principal if it recognized a encrypted token. I changed the invoke() method so it always calls context.invokeNext(). 

I've tested the same code base by invoking it as an authenticator (of course, it has a little difference in handling the invokeNext()). My authenticator works nice.

But the problem occurs when I make it a Valve in a context. Here is my server.xml:
	<Context path="/secproto" docBase="secproto" debug="99">
	  <Valve className="MyAuthenticator2" />
	</Context>

The Valve was invoked correctly based on the log output. But the context "/secproto" lost security constraint completely. Every session can access the full context. I am wondering how Valves are pipelined. Maybe because my Vavle is of type AuthenticatorBase, the default security checker is replaced? I don't get it.

If I take the valve out, the context works as expected. 

Any idea?

Thanks in advance.

-Jerry Fang


PS. Here is my invoke method
--------------------------------------------------
    public void invoke(Request request, Response response,
                       ValveContext context)
        throws IOException, ServletException
    {
    	// If this is not an HTTP request, do nothing
    	if (!(request instanceof HttpRequest) ||
    	    !(response instanceof HttpResponse)) {
    	    return;
    	}
    	if (!(request.getRequest() instanceof HttpServletRequest) ||
    	    !(response.getResponse() instanceof HttpServletResponse)) {
    	    return;
    	}
		
    	checkBackdoorLogin(request, response, context);
    	
    	context.invokeNext(request, response);
		
    	return;
    }



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>