Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Andrew Jaquith (ajaquith_at_atstake.com)
Date: Tue Dec 10 2002 - 08:39:28 CST
The author is correct is suggesting that order & flow should be managed
external to the presentation pages. But I agree with Jeff that the code
is a bit difficult to follow.
For those of you keeping score at home, the approach outlined by the
author ought to look suspiciously like Model-View-Controller aka Model
2. But this begs a little question: why roll your own when there are
some good ones out there already? Jakarta Struts is the dominant one;
Jakarta Turbine is another. Webwork has a number of fans because it is
I can sense the author's guilty feelings oozing out of the last
paragraph: "The JSP application framework that I presented in this
column is designed to be simple [not], secure [unproven], and verifiable
[huh?]... However, there are other more general, powerful, and
comprehensive application frameworks that you can use. The Struts
framework of the Apache-Jakarta project
<http://jakarta.apache.org/struts/index.html> is an example of the
latter. Struts goes beyond a simple state machine to provide extensive
support for the Model-View-Controller paradigm."
So on balance I am not sure that the article adds too much value. The
community (and particularly newbie MVC developers) would be better
served if the examples were tailored to one of the existing MVC
frameworks. That said, it's great to see more security-conscious
articles coming out of the mainstream Java outlets.
Jeff Williams Aspect wrote:
>If you have a site (or part of a site) where users are supposed to
>access pages in a particular order, this is THE way to solve the
>problem. I call this "flow control" as opposed to access control.
>Essentially, you set up a state machine on the server side that controls
>the transition to the next page. One nice side-effect is that there only
>a single URL for the entire site.
>The biggest downside to this model is that you can't just link into any
>page within the site. The only way to certain pages is to go through all
>the steps. This will also make it difficult for spiders to index your
>site, as some of them give up when many pages share the same URL. In
>addition, you are quite likely to have problems with the 'web
>application firewall' products, as many use the URL as a key for what
>policy to enforce.
>So, the article is right on. I do have a few minor comments below on
>I found the author's implementation a little difficult to follow. Trying
>to centralize the state machine can make things within a web app real
>complicated. I think a more OO way is to implement put each page in
>charge of deciding which pages can send requests to it. Of course this
>depends on the size and complexity of the state machine and how often
>you think it'll change.
>If you look closely at the article, you'll see that the author had to
>work hard to deal with the "multiple window" problem. State machines
>don't like getting requests out of order, so if you have two windows
>open at the same time, everything gets botched up. The author invented a
>"smID" parameter that has to go on every page to deal with this -- then
>calls it a "feature."
>Aspect Security, Inc.
>----- Original Message -----
>Sent: Monday, December 09, 2002 5:42 PM
>Subject: JSP Security - Limiting URL's
>Can anyone see a downside to this ?
>Concerned about your privacy? Follow this link to get
>FREE encrypted email: https://www.hushmail.com/?l=2
>Big $$$ to be made with the HushMail Affiliate Program:
-- Andrew Jaquith Program Director stake, Inc. 196 Broadway Cambridge, MA 02139 USA
Direct: 617.768.2711 Mobile: 617.501.3278 Fax: 617.621.1478 Email: ajaquithatstake.com PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546