Morten,
HttpServletRequest is simply an interface. If you wanted to subclass it,
you would have to implement every member of the interface. However, you
could do this easily enough by passing every method that you didn't want to
implement to the original request object, for example:
public class MySpecialHttpServletRequest implements HttpServletRequest
{
private HttpServletRequest origRequest;
public MySpecialHttpServletRequest(HttpServletRequest origRequest)
{
this.origRequest = origRequest;
}
public String getAuthType()
{
return origRequest.getAuthType();
}
etc.
public boolean isUserInRole(String role)
{
// Do your own stuff
}
}
And then in your JSP you would have something like
<%
request = new MySpecialHttpServletRequest(request);
%>
However, if I were thinking of implementing an entire J2EE interface simply
to handle a single method, I'd be questioning whether I was going in the
right direction. If you have something that is working, you may want to
consider keeping it. Alternatively, why not try to use Tomcat's role-based
security architecture rather than overriding it?
Something else that occurs to me is that your security model appears to
depend on a GET parameter in the request ("?site=MySite"). A client could
easily change this value to circumvent your security. A better model is
that your logon page sets a value in the Session object to identify the
user. Then the security depends on a very long, random session ID and it is
vanishingly unlikely that a client will be able to change this ID (either in
a URL or a cookie) and, by chance, hit on a valid session ID belonging to
another user.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
