struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhou" <>
Subject MVC, Security, and Redirect
Date Wed, 02 Jul 2003 09:37:11 GMT

The following is my experience about the subject over the
years and also includes what I learned so far.

What is the best practice for the security checking with
the MVC design pattern? Over the years, I learned that
the Struts developers have been using the following ideas
for the security checking as the best practice.

1) No one has direct access to any JSP pages in the 
    web applications.
2) Anybody is able to invoke the generalized action
    controllers where the security checking is performed.

The rules are simple and crystal clear. They come from
the minds of the true MVC experts. When the redirect is
a question, we can not isolate the MVC and Security 
context to give an answer, especially to make

This is because redirecting to a JSP page will not work
under rule one. So we normally redirect to an action. If the
security checking is performed in the base class of the
generalized action controllers for rule two, the protections
for all of the JSP pages are uniformly enforced.

So it is misleading if someone's message is suggesting
the action is protected by the security constraints. It is
the same misleading thing if the message is suggesting
the security constraints could allow the JSP pages to be
accessed directly by authorized users in order to make
the redirect to work. Because if the servlet container is
configured that way, end users may work around the
security checking in rule two by directly accessing to
the JSP pages. They might be able to obtain some
unauthorized information - the same problems where
Model 1 things may have.

A clear understanding to the two rules is very important
when dealing with the redirect. The following link
provides detail information on how Carrier implements
the two rules.

When considering the location where the JSP pages
should be protected. We realized that WEB-INF is
suitable for self-service type of web applications (or
say developed for self use)
Since Carrier is designed as a multi-vendor solution
carrier, the packaged solutions must be highly
modular and the best way is to put the packaged
solutions under the security constraints with a nobody
dummy role.

What I enjoyed in the MVC/Security is the conciseness
of the two rules. I gave Carrier the most concise
implementation - only one default controller class
for all business logics as well as the redirect logics in
our demos.


Netspread Carrier

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message