Re: [agile-usability] Back button
> > From: Lisa Crispin [mailto:lisa.crispin@...]It's been a while for me on this too. We rejected (pure) client-side
> > How do most people handle problems that could arise from an end user
> > clicking the back button? Is there a simple trick? Like not
> > putting the page on the history or something?
>On Tue, 23 Nov 2004 19:49:29 -0500, Mike <michael.net@...> wrote:
> I'm not 100% sure but I think that client-side solutions will never work reliably
> [...] I believe the only real solution involves comparing a session token to a
> viewstate (or hidden field) token on the server.
solutions as well: if you assume the possibility of a malicious user
(who can't?), you have to.
Our solution was:
- use generated pages for this part of the process (so it didn't help
to save URLs)
- maintain a session key in the generated page, passing it back with the query
- use some encryption tricks so users can't just make up a session key
- make session keys temporary (expiring in say an hour) and one-use-only
- maintain the state on the server ("this session is in step 3 of the
checkout process; if anything except a cancel or a move to step 4
comes in, back out to safe place")
We only applied this in a couple key places (in a sort of checkout
process where you wanted non-repudiation).
I would have thought that more modern tools would take care of this in for you.
Bill Wake William.Wake@... www.xp123.com
- --- In email@example.com, "aacockburn" <acockburn@a...>
> --- In firstname.lastname@example.org, "Jeff Patton"
> wrote:I think yesterday's weather confirms your thinking.
> > Things to try:
> > Capture more durable information in wiki pages. [use the
> > wiki set up by Adina Levin? thanks for doing that btw]
> I'm thinking that the eGroup is good for noisy discussion and back-
> and-forth, and wiki is good for archiving.