Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Message-ID: <012101c3407d$83f4e420$6400a8c0@carrier>
Reply-To: "Jing Zhou" <jing@netspread.com>
From: "Jing Zhou" <jing@netspread.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Subject: MVC, Security, and Redirect
Date: Wed, 2 Jul 2003 04:37:11 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_011E_01C34053.9A6C2DF0"

------=_NextPart_000_011E_01C34053.9A6C2DF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,

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=20
    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=20
context to give an answer, especially to make
recommendations.

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
http://www.netspread.com/tips2.html#mvc
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.


Regards,

Jing
Netspread Carrier
http://www.netspread.com


------=_NextPart_000_011E_01C34053.9A6C2DF0--