I have a question about the last paragraph of you answer.
Regards
Zhongwu
> -----Original Message-----
> From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, August 15, 2001 11:40 AM
> To: Tomcat User's Group; [EMAIL PROTECTED]
> 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
>
