"force" user to use site in defined order?

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> writes:

IBTD. Did you or did you not suggest that storing cookies or form
data would be a way to "'force' [a] user to use [a] [Web] site in
[a] defined order?

I have disproved that.

Either will work if the right measures are taken.

1) Generate a global encryption key for the application.

2) When the user arrives at page 1, encrypt '1' together with a unique
identifier for the user, and set it as a cookie or hidden form
field. Send the unique identifier unencrypted as well.

3) When the user arrives at page 2, decrypt the cookie or hidden form
field and check that it contains '1' and the unique identifier. If
it doesn't, redirect to page 1. If it does, generate a new one
containing '1,2'.

4) Repeat as needed for future pages, alternative branches, etc.

While the user can obviously send whatever form or cookie data they
like back to the server, the server has a straightforward way to
validate that the 'previously visited' data is data that it generated
(up to the security of the key and encryption algorithm, of course)
and reject modified data.

The unique identifier is to stop someone finding out what the
encrypted value of '3' is for a particular application and jumping
straight to page 3. You could alternatively generate a unique
encryption key for each user.

--
Chris

Ben Bacarisse wrote:

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> writes:
Ben Bacarisse wrote:
Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> writes:
Ben Bacarisse wrote:
snip
If cookies are not acceptable, you can do this with form data.
Cookies are as susceptible to a forging attack as is form data.
http://getfirebug.com/ and see how easy it actually is.
Of course. I never suggested otherwise.
IBTD. Did you or did you not suggest that storing cookies or form data
would be a way to "'force' [a] user to use [a] [Web] site in [a]
defined order?

What has that got to do with it? I did not suggest that cookies were
any less susceptible to being "forged" and you seemed to think I had.

No, I said that one approach (that you dismissed) is as suspectible to a
forging attack as the other one (that you mentioned as a proper
replacement). That is quite a different thing.

F'up2 comp.infosystems.www.authoring.misc

The usual practice is to set a followup-to header in order to limit
the discussion to more suitable groups. You seem to have just added
comp.infosystems.www.authoring.misc. Why do you think more people
want to see this?

Temporary malfunction on layer 8 in interaction with layer 7.

Interestingly, you forgot to set the Followup-To header as well, so I guess
we are even now


F'up2 ciwam

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

Tue, 01 Apr 2008 14:15:07 +0100, /Geoff Cox/:

Thanks everyone for the useful comments - will work through them now.

Just wanted to point out there are frameworks which can manage the
thing for you, like the "Seam conversations":

http://docs.jboss.com/seam/2.0.1.GA/...l.html#d0e1568

But using specific framework may not be applicable, often.

--
Stanimir