|
|
Posted by shimmyshack on 03/21/07 22:12
On Mar 21, 3:13 pm, "Aetherweb" <jeffs...@gmail.com> wrote:
> On Mar 21, 3:08 pm, "kenoli" <kenol...@gmail.com> wrote:
>
> > I can't add anything to the great advice you've gotten except to point
> > out that sessions do involve using a cookie, something you mentioned
> > you didn't want to do.
>
> Sessions do not need to involve a cookie if you include the session ID
> on every URL a user clicks on.
>
> What you will struggle with, however, is storing the state of play of
> the game in progress without writing to a database or file at some
> point.
It has to be said that *any* data passed as a result of playing the
game will be alterable, but the idea behind using a session is that
you dont have to carry the full weight of the variables on each round
trip.
You could, say encrypt a string and send it as a hidden field, (rather
like the postback, but using real encryption)
there are many possibilities, but ultimately the convienience of a
session wins through.
Although it does involce a cookie - it is one handled entirely with
javascript as a HTTP header, and does not need to be interacted with
in any way with client logic, the logic is all server side, the only
thing the client does is handle the posting of the data0
When using the session ID in the URL as a query string, (or indeed
storing it somewhere in the markup) you trade the lack of a cookie,
with the high visibility to a casual onlooker (or proxy log etc..) of
the session ID which can enable full session privs without needing to
know the password. At least a header is slightly less obvious, but of
course is still interceptable.
Navigation:
[Reply to this message]
|