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.
> -Jerome
Craig McClanahan
