Let's say you have a page where you have 3 or 4 steps (different pages) a user has to take, and at each step, user variables get set that the next step relies on.
Now, let's say someone attempts to go straight to the 3rd step with an expired user key (because of bookmarking the page, following a google link or whatever). The server assigns a new user key but still, the varibles that step 3 relies on wont be set because steps 1 and 2 weren't done. It's easy of course to trap this problem by just testing for the existance of the user variables at the beginning of the step but guess what, that is also how you test for the validity of the user session! So, even if the server assigned new user ref keys for expired/invalid sessions, you would still be having to do the same test as if the server didnt assign a new key anyways, which means unnecesary inneficiency of the server and who wants that?? :P ----- Original Message ----- From: "Stefan Gonick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 13, 2004 2:09 PM Subject: Re: Witango-Talk: Cookies > You are right that there are still scenarios where a session never > expires. Those would have to be dealt with. > > However, the system would be a lot more secure with less effort > for the more usual cases if it worked the way that I described. It > doesn't seem like a big deal to make it work that way. I imagine > that it's not hard for the server to determine if a session is active > or not. If it's not, then generate a new userref. The new userref > will automatically get picked up by the @userreferenceargument. > > Stefan > > At 05:05 PM 10/13/2004, you wrote: > >But what if UserRefA never expires. How could that happen you ask? > > > > > >I copy my UserRefA and post it in my blog. Before it has expired, > >people start hitting the site, all with UserRefA. Meanwhile, google > >comes along, indexes my blog, and still more people follow the link. > > > > > >On Wednesday, October 13, 2004, at 01:55 PM, Stefan Gonick wrote: > > > >>Here's my problem: > >> > >>The whole point of the @userreferenceargument was to handle the > >>case where cookies are turned off! I do not accept the final solution > >>of telling visitors that they have to change their browser settings in > >>order to use my site. I'm sure that they would just leave in that case. > >>Savvy users would not have turned off session cookies in the first > >>place. Naive users would be scared to do it. > >> > >>It seems to me that there is a deficiency in the system. This is > >>how I think that the server should work: > >> > >>A user comes in with old UserRefA. The server checks to see if > >>there is a currently active session with that userref. If not, then it > >>discards UserRefA and generates a new one. This solves the problem! > >>This allows us to continue to use @userreferenceargument as a > >>useful way of handling browsers with cookies turned off. It should > >>never reuse an inactive/expired userref. > >> > >>I agree with the new precedence rules, but @userreferenceargument > >>should always be a viable fall-back when cookies are off. > >> > >>Hello, With Enterprise? > >> > >>Stefan > >> > >>At 04:37 PM 10/13/2004, you wrote: > >> > >>Hi Stefan, > >> > >> > It seems to me then that the system would be more secure if the > >> > Witango server always assigns a new userref when encountering > >> > an old expired one when cookies are off rather than reusing the old > >> > one. > >> > Does this make sense to anyone? > >> > >>No. > >> > >>Your solution is more complex that it needs to be. The Witango server > >>should never, under any > >>condition, be concerned that cookies are disabled. > >> > >>Your code, on the other hand, may want to be concerned with cookies - > >>but that's another matter. > >> > >> > >> > >> > It would be great if With joins in at some point and explains how > >> > the server actually is designed to work in these scenarios. > >> > >>I can't speak for them, but I can tell you they have been involved > >>more than once in this > >>discussion (which we've had more than once). > >> > >>The conclusion, as best as I can summarize (and the way I see it), is: > >> > >>The <@USERREFERENCEARGUMENT> metatag has been depreciated to a level > >>of functionality that > >>provides some user convenience but nothing more - and that newer > >>versions of the Witango Server > >>architecture gives this metatag a lower level of precedence during > >>session evaluation. > >> > >>Basically, stop using <@USERREFERENCEARGUMENT>. > >> > >> > >> > >>_______________________________________________________________________ _ > >>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > >> > >> > >> > >>===================================================== > >>Database WebWorks: Dynamic web sites through database integration > >>http://www.DatabaseWebWorks.com > >________________________________________________________________________ > >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > > ===================================================== > Database WebWorks: Dynamic web sites through database integration > http://www.DatabaseWebWorks.com > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
