On Tue, 01 Apr 2008 06:54:05 +0100, Geoff Cox <gcox@freeuk.notcom>
wrote:

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

Cheers

Geoff

Ben Bacarisse wrote:
> Geoff Cox <gcox@freeuk.notcom> writes:
>> On Tue, 01 Apr 2008 06:04:36 GMT, "rf" <rf@invalid.com> wrote:
>>> "Geoff Cox" <gcox@freeuk.notcom> wrote in message
>>> news:h3j3v315jrg4ttj011l8r0ajodatgasaas@4ax.com...
>>>> I am preparing a site where it is important that the user moves from
>>>> page 1 to page 2 to page 3 etc as a series of tests are presented and
>>>> the order is important.
>>>>
>>>> Is it possible to make sure that this happens?!
>>> No.
>>
>>> Make the all the same page and control the content server side, probably
>>> with a session.

Full ACK.

> [...]
> You store a on the client side. Your server displays page one
> if the is missing. Page one sets the to show that page
> 1 has been seen. The "next" button just re-loads the page but now the
> server will show page 2. Rinse and repeat.
>
> If are not acceptable, you can do this with form data.

are as susceptible to a forging attack as is form data.
http://getfirebug.com/ and see how easy it actually is.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
<snip>
>> If are not acceptable, you can do this with form data.
>
> 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.

--
Ben.

Ben Bacarisse wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
> <snip>
>>> If are not acceptable, you can do this with form data.
>> 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 or form data
would be a way to "'force' [a] user to use [a] [Web] site in [a] defined order?

I have disproved that.


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

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
> IBTD. Did you or did you not suggest that storing 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 or hidden form
field. Send the unique identifier unencrypted as well.

3) When the user arrives at page 2, decrypt the 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 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

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>> <snip>
>>>> If are not acceptable, you can do this with form data.
>>> 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 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 were
any less susceptible to being "forged" and you seemed to think I had.

> 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?

--
Ben.

Ben Bacarisse wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> Ben Bacarisse wrote:
>>> <snip>
>>>>> If are not acceptable, you can do this with form data.
>>>> 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 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 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