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
