I guess, there IS a way to forward the .jsp processing to tomcat's
jsp-servlet, even when you have registered your own servlet to process all
.jps requests.
Instead of using
ServletContext.getRequestDispatcher(url).forward(request, response);
use
ServletContext.getNamedRequestDispatcher("jserv-servlet").forward(request,
response);
It worked for me.
Note: This method does not work if you want to "re-write" the url in your
handler servlet. JSP files processed by the jserv-servlet is always the URL
of the original request.
Kedar
----- Original Message -----
From: Craig R. McClanahan <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, November 30, 2000 11:27 PM
Subject: Re: MVC problem
> See below.
>
> "Aiken, David" wrote:
>
> > > hi all..
> > >
> > > We're hitting a problem with the MVC approach in tomcat.
> > >
> > > Our controller is designed to intercept all requests for URLs within
our
> > > web application so that it can handle internationalization and
security
> > > checks centrally.
> > >
> > > The problem is as follows:
> > > - the controller servlet registers interest in URLs of the form
'*.jsp'
> > > - a request for 'a.jsp' arrives and the controller checks security and
> > > negotiates the locale settings
> > > - the controller includes the contents of 'a.jsp' in the response
> > >
> > > At this point it seems that tomcat takes over. Unfortunately, it
doesn't
> > > retrieve the contents of the page - it just resubmits the request to
the
> > > controller again, resulting in an endless loop. This also occurs for a
> > > 'forward'. Not good.
> > >
> > > One of the workarounds is to use URLs of the form '.do' to request
page
> > > content. This allows the controller to forward to a .jsp URL without
> > > getting into a loop. The problem is that someone who knows the
structure
> > > of the www site can submit requests for '.jsp' directly and bypass any
> > > security checks. The obvious workaround for this is to put tags into
the
> > > .jsp pages and java calls into any servlets to perform the security
check
> > > - but this negates any advantage to the MVC approach (and forces
> > > page/servlet developers to remember to place checks into all of their
> > > content).
> > >
> > > We're probably missing something - it seems difficult to believe that
the
> > > MVC approach has such a fundamental flaw.
> > >
> > > thanks!
> > > David Aiken
> > > BMC Software
>
> What you are hitting is primarily a limitation of the way that servlet
mappings
> work in servlet 2.2. If you define a servlet mapping that maps the
"*.jsp"
> extension to the JSP servlet (as Tomcat does by default), then the JSP
servlet
> will be executed -- bypassing your security checks. If you register the
"*.jsp"
> extension to your own servlet, then you will receive the request -- but
there is
> no way to forward control later to get the JSP page executed.
>
> This kind of issue was one of the motivating factors for the Filter API of
the
> new servlet 2.3 spec (which Tomcat 4.0 supports). This lets you register
> filters that can preprocess (and postprocess, if you want) requests to
> particular URI patterns, completely independently of which servlets will
> actually process those requests.
>
> For your use case, you could write a filter that is mapped to the "*.jsp"
> extension. It would look at the request, before the JSP system ever sees
it.
> If your security checks are satisfied, simply pass the request on through
the
> filter chain, which will cause the page to be executed in the usual way.
If a
> check fails, you can redirect the user to an error page instead.
>
> Craig McClanahan
>
>
