> 3. in general this can be handled OK if the site has an entry point
> that performs authentication and then records the successful login in
> the session. Any leap into the site behind this URL via a bookmark
> will fail because the session will not exist or will not contain the
> "successful login marker".
Agreed. Most sites that require logon work this way. The application simply
checks the session object, if it is not there or is not marked as "logged
on", a new session is started and the person is redirected to a logon page.
> 4. Actually I've no problem with multiple browsers with discrete sessions.
> This is just another user - just like someone on another machine.
> It's when they share the same session that problems can occur.
> Note of course that the stateless nature does mean that you have to be
much
> more
> careful with concurrency and locking on the persistence layer.
> This is a very important topic that requires detailed understanding of the
> application, RDBMS and data model.
I would hope that nobody is keeping a lock on a database between pages!
Don't do it. Keep each page separate. Even if it takes 3 pages to make a
"real" transaction, treat each of the three pages as separate transactions
that build up the information needed to complete the "real" one once the
third page is done. If they never complete page 3, then you have a choice
to remember this until they come back, or you can cleanup once the session
expires.
> 1. I think this can be solved somewhat by setting the headers to expire
the
> pages and turn off caching. Of course we've all seen the million emails
> expressing frustration at determining the exact sequence of headers needed
> for each stupid browser.
So you know that you'll never get it to work, then, right? <smile> Besides,
don't do it. People are always trying to disable the BACK/FORWARD buttons,
but that's lame for a browser since the whole world understands that
metaphor. If you want to play with a web browser, you need to code your
applications to handle typical web browser usage. Otherwise, consider
writing a client or plugin or java applet.
> 2. This is the real pain.
> The only thing I can say initially is that I do not think it appropriate
to
> encapsulate complete state in each page - a snapshot that rapidly becomes
> out-of-date if multiple windows are open and active.
I'm not sure what I wrote, but the idea isn't to encapsulate the entire
state in the web page. That can even be a security hole since people can
see hidden state and change it before posting back. I've seen sites that
store the userid/password as hidden fields, which is really weak and of
course exposes the person's security info to anybody who takes a look at the
page!
The basic idea of a state machine is okay, assuming you can identify the
state transitions in a simple way. At one level or another, most business
logic that requires multiple steps employs a state machine of sorts. The
key is simply to make sure that any given transaction the user does from a
page makes sense at the time it occurs. So, if a user adds a record, then
does a BACK and hits the add button again, the user should either get two
records or an error about it being a duplicate. Trying to prevent BACK will
never work since you cannot stop people from using this useful metaphor nor
opening multiple windows on the same browser instance.
The key is in data validation. Whenever a request comes in, you have to
check that the request is valid. In general, avoid forcing a user to follow
a given set of steps in a particular order (this is a modeless model that
GUIs and the web have made quite powerful and useful to people) -- other
then when doing a wizard. Even most wizards will let you go back and
forwards through the steps you've already done.
david
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
