RE: Does the servlet security model work with the J2EE Blueprint MVC?

["Lin, Zhongwu" <Zh...@AFCC.com>]

I have a question about the last paragraph of you answer.

Regards

Zhongwu

> -----Original Message-----
> From:	Craig R. McClanahan [SMTP:craigmcc@apache.org]
> Sent:	Wednesday, August 15, 2001 11:40 AM
> To:	Tomcat User's Group; jerome.jacobsen@gentootech.com
> Subject:	Re: Does the servlet security model work with the J2EE
> Blueprint MVC?
> 
> 
> 
> On Wed, 15 Aug 2001, Jerome Jacobsen wrote:
> 
> > Hello,
> > 
> > The Java Servlet Specification (Version 2.3, Draft 2) under SRV.12.2
> states:
> > 
> > "The security model applies to the static content part of the web
> > application and to servlets within the application that are requested by
> the
> > client. The security model does not apply when a servlet uses the
> > RequestDispatcher to invoke a static resource or servlet using a
> forward()
> > or an include()."
> > 
> 
> In other words, the security constraints are only matched on the initial
> request URI, not on paths passed to getRequestDispatcher().
> 
> > Does this mean that using the MVC architecture with a Web controller as
> > described in the J2EE Blueprints precludes the use of this security
> model?
> > 
> 
> Not at all.  You've got at least a couple of approaches to consider:
> 
> * If your MVC architecture uses different URIs for different logical
>   transactions (i.e. you are using either path mapping or extension
>   mapping to map to the controller component) you can protect those
>   URIs with appropriate security constraints.
> 
> * Your controller component can (in addition to or instead of the
>   restrictions based on security constraints) apply additional role-based
>   checking -- perhaps defined in the configuration settings for the
>   controller -- by calling request.isUserInRole() to check whether the
>   user is authorized for one or more roles.
> 
> * Roles can also be used in the view layer to change the presentation
>   (for example, a manager might have more menu options to choose from
>   than a regular user).
> 
> In an MVC-architected web app, your primary concern is whether the user
> can perform the transaction that they requested.  If they can, you
> naturally want them to see the results of performing that transaction, so
> there is no need to protect the RequestDispatcher.forward() used by the
> controller to forward control to the ultimate view component.
> 
> But what if you have users that try to navigate to your JSP pages directly
> (and perhaps bookmark them).  You can take advantage of a related
> specification requirement, and put those JSP pages inside the /WEB-INF
> directory.  This works because the container will refuse to serve anything
> under /WEB-INF directly to the user, but RequestDispatcher.forward() can
> still be used to display them.
> 
	[Lin, Zhongwu]  
	can you explain in more detail on the last paragraph:
	put those JSP pages inside the /WEB-INF
	directory.  This works because the container will refuse to serve
anything
	under /WEB-INF directly to the user, but RequestDispatcher.forward()
can
	still be used to display them.
	[Lin, Zhongwu]  How do I reference those JSP pages inmy app?
	should I do like:
	/WEB_INF/mypage.jsp   

> > -Jerome
> 
> Craig McClanahan
> 

RE: Does the servlet security model work with the J2EE Blueprint MVC?

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 15 Aug 2001, Lin, Zhongwu wrote:

> I have a question about the last paragraph of you answer.
> 
> 	[Lin, Zhongwu]  
> 	can you explain in more detail on the last paragraph:
> 	put those JSP pages inside the /WEB-INF
> 	directory.  This works because the container will refuse to serve
> anything
> 	under /WEB-INF directly to the user, but RequestDispatcher.forward()
> can
> 	still be used to display them.
> 	[Lin, Zhongwu]  How do I reference those JSP pages inmy app?
> 	should I do like:
> 	/WEB_INF/mypage.jsp   
> 
> > > -Jerome
> > 
> > Craig McClanahan
> > 
> 

Let's start with a simple experiment.  Start up Tomcat and request the
following URL:

  http://localhost:8080/examples/WEB-INF/web.xml

What happens?  You get a 404 error, even though the web.xml file is really
there.  This is based on a Servlet Specification restriction that
*nothing* inside the "/WEB-INF" directory may be served directly to a
client in response to a request.

However, it is legal to access these contents from within a servlet or JSP
page, or access them through a request dispatcher.  For example, I could
read the contents of web.xml myself like this:

  InputStream is =
   getServletContext().getResourceAsStream("/WEB-INF/web.xml");

or, if I have a JSP page "foo.jsp" in the /WEB-INF directory, I can do
this:

  RequestDispatcher rd =
   getServletContext().getRequestDispatcher("/WEB-INF/foo.jsp");
  rd.forward(request, response);

or (from a JSP page):

  <jsp:forward page="/WEB-INF/foo.jsp">

This works because the access is from *inside* the web app, whereas the
following request (from a client) will generate a 404:

  http://localhost:8080/examples/WEB-INF/foo.jsp

In summary, if you are using an MVC style application architecture like
that proposed in J2EE Blueprints (or in Struts), you can easily make it
impossible for your users to navigate directly to a page without going
through the controller first.

Craig