Re: MVC problem
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
Re: MVC problem
I believe one solution offerred previously on this list (thank you Craig!) was to place all of your .jsp pages underneath /WEB-INF (e.g. /WEB-INF/jsp/...) Since these can never be served up (goes against the jsp/servlet spec) HTH, Mike At 11/30/2000 10:20 AM -0600, you 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
RE: MVC problem
That sounds workable.. i looked for an archive of this newsgroup but didn't have any luck - do you know where the relevant section in the JSP/servlet spec is? thanks! david -Original Message- From: Mike La Budde [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 10:54 AM To: [EMAIL PROTECTED] Subject: Re: MVC problem I believe one solution offerred previously on this list (thank you Craig!) was to place all of your .jsp pages underneath /WEB-INF (e.g. /WEB-INF/jsp/...) Since these can never be served up (goes against the jsp/servlet spec) HTH, Mike At 11/30/2000 10:20 AM -0600, you 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
Re: MVC problem
"Aiken, David" wrote:
That sounds workable.. i looked for an archive of this newsgroup but didn't
have any luck - do you know where the relevant section in the JSP/servlet
spec is?
Do you mean the restriction on serving things from WEB-INF directly to the
client?
Servlet 2.2 Spec, Section 9.4, p. 44 (last sentence of the first paragraph).
Servlet 2.3 Spec (Proposed FInal Draft), Section 9.4, p. 59 (last sentence of
the second paragraph in this section).
Basically, the prohibition means that the following sorts of URLs:
http://localhost:8080/myapp/WEB-INF/web.xml
will return an error instead of exposing potentially sensitive configuration
information in your deployment descriptor.
A servlet can still access things under WEB-INF -- for example, the JSP servlet
needs to read web.xml when you use custom tags (to look for taglib elements),
and it does this:
InputStream is =
getServletContext().getResourceAsStream("/WEB-INF/web.xml");
You can do the same with other configuration files that contain sensitive stuff
-- the WEB-INF directory is a good place to put them.
thanks!
david
Craig
PS: Yes, I *have* almost memorized the specs over the last couple months :-)
Re: MVC problem
"Aiken, David" wrote:
"No file contained in the WEB-INF directory may be served directly to a
client."
That seems pretty clear.. we tried directly accessing JSP pages using a URL
of the form http://localhost:8080/examples/WEB-INF/index.jsp and it
delivered the page using tomcat 3.2 on a W2K system - is it necessary to
configure something to enforce this restriction?
Yep (grrr ... happens in 3.2 final and 4.0 current code).
Both of these versions have traps to avoid serving static files from WEB-INF
(even if you try to circumvent it on non-case-sensitvie platforms with things
like "/WeB-iNf/web.xml"). It never occurred to me that anyone would ever put a
JSP page there :-(.
We're also wondering about restricting access to servlets.. we could require
our developers to use a servlet subclass, but this would be non-MVC-like. Is
there a way to govern access to them from a controller servlet?
One approach that will work in Tomcat 4.0 (because it was planned that way in
the servlet 2.3 spec) is based on the following reasoning:
* Security constraints are imposed only on the original request URI,
not when doing RequestDispatcher.include or RequestDispatcher.forward
* Therefore, we can prohibit direct access to servlets (or JSP pages) by
protecting them with a security constraint that disallowed access.
* In 2.3, if you define a security contraint that has an auth-constraint
element with no nested role-name elements, the container interprets
this to mean that absolutely no direct access to the protected URIs
is allowed via requests -- they can only be accessed indirectly via
a RequestDispatcher.
* You can simulate this behavior in 2.2 by using a security constraint with
a role-name to which no users have been assigned.
Doing this forces all requests to come through your controller servlet, because
none of the JSP pages would be directly accessible.
thanks!
david
Craig
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 30, 2000 12:43 PM
To: [EMAIL PROTECTED]
Cc: '[EMAIL PROTECTED]'
Subject: Re: MVC problem
"Aiken, David" wrote:
That sounds workable.. i looked for an archive of this newsgroup but
didn't
have any luck - do you know where the relevant section in the JSP/servlet
spec is?
Do you mean the restriction on serving things from WEB-INF directly to the
client?
Servlet 2.2 Spec, Section 9.4, p. 44 (last sentence of the first paragraph).
Servlet 2.3 Spec (Proposed FInal Draft), Section 9.4, p. 59 (last sentence
of
the second paragraph in this section).
Basically, the prohibition means that the following sorts of URLs:
http://localhost:8080/myapp/WEB-INF/web.xml
will return an error instead of exposing potentially sensitive configuration
information in your deployment descriptor.
A servlet can still access things under WEB-INF -- for example, the JSP
servlet
needs to read web.xml when you use custom tags (to look for taglib
elements),
and it does this:
InputStream is =
getServletContext().getResourceAsStream("/WEB-INF/web.xml");
You can do the same with other configuration files that contain sensitive
stuff
-- the WEB-INF directory is a good place to put them.
thanks!
david
Craig
PS: Yes, I *have* almost memorized the specs over the last couple months
:-)
MVC problem
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
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
