tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: j_security_check
Date Fri, 09 Nov 2001 16:29:47 GMT

On Fri, 9 Nov 2001, Frank Lawlor wrote:

> Date: Fri, 9 Nov 2001 09:42:13 -0600
> From: Frank Lawlor <>
> Reply-To: Tomcat Users List <>,
> To: 'Tomcat Users List' <>
> Subject: RE: j_security_check
> Craig R. McClanahan wrote
> >
> > So where was everyone when Servlet 2.3 was in "Public Review"
> > or "Proposed
> > Final Draft" state (almost ten months)?  Where was the public feedback
> > that said "please fix this"?  (responsibility 101).   Sheesh ...
> >
> Craig,
> Sorry.  I didn't mean that as a personal
> shot at you.

I know you didn't.

But (from a spec development point of view) it's a little frustrating to
find out about stuff like this after the fact, rather than before.  The
JCP process includes public review period before the specs go final -- and
Tomcat 4 was available in beta throughout that period for experimentation.
It is our responsibility of users of these technologies to make sure we
point out potential problems *before* the spec goes final, so there is the
opportunity to affect it.

> But it is important that we recognize
> usability problems as they occur and
> try to fix them rather than the users.

Note that older versions of Tomcat employed one of the suggested
alternatives (RequestDispatcher.forward() to the login page), but this
generated bug reports that relative image links on the login page didn't
work right (same issue you have in any MVC type framework that uses
forwards).  Sometimes you can't win ... :-)

Web applications, in many cases, are different beasts than web sites --
they are not designed to be browsed or surfed any more than a GUI
application based on Swing is.  If your user population doesn't understand
that, they (and you) are going to be frustrated -- and you'll get bug
reports when a shopping cart lets you add the same item multiple times
because your user used the back arrow ...

So, web app designers have to deal with this anyway, and it's not just
the login page URL that you need to protect.  You can use defensive
measures (detect when the back arrow was used to submit the same form
again), but a very effective technique is to just hide the locations
completely.  A couple of approaches I have seen used:

* If you are not already using frames, create a single
  frame that contains the entire application window.
  The location bar on the browser never changes, so the
  user isn't tempted to bookmark it

* Create a new application window that doesn't have a
  location bar, or arrows.  Determined users who know
  the keyboard shortcuts can still try to mess things
  up (so the defensive techniques are still needed),
  but you've at least avoided tempting a beginner to
  get himself or herself in trouble.

In usability tests, if your user is even tempted to use the browser's
controls (after they have become at least a little familiar with the app),
I consider that a signal that there is probably not enough navigation
capability within the app's pages itself.

> So, is there some place I can suggest
> a change to the spec?

The feedback address is on the front of the Servlet Spec (and every Java
spec, for that matter).  In the case of servlets, its at:

Unfortunately (from the point of view of changing anything), the 2.3 spec
just went final (after an extended public review period), so nothing can
be changed until 2.4.

> Thanks,
> Frank Lawlor
> Athens Group, Inc.
> (512) 345-0600 x151
> Athens Group, an employee-owned consulting firm integrating technology
> strategy and software solutions.


To unsubscribe:   <>
For additional commands: <>
Troubles with the list: <>

View raw message