Re: "force" user to use site in defined order?
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.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?
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
Chris Morris
> 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
> Ben Bacarisse wrote:
>> Thomas 'PointedEars' Lahn <Point...@web.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.
> 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.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <Point...@web.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
Stanimir Stamenkov
> 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/reference/en/html/tutorial.html#d0e1568
But using specific framework may not be applicable, often.
--
Stanimir