If you don't remove the problem, then you either deal with it (by crafting your own way of uniquely identifying user-agents) or you accept the consequences.
In fact, the user scope variables that correspond to the "expired" user reference no longer exist. So if you're willing to allow multiple anonymous users to all appear to your system to be identical, then it doesn't matter what the userreferenceargument is, so not using one is the same as using the same one multiple times.
On Wednesday, October 13, 2004, at 02:37 PM, Stefan Gonick wrote:
I'm thinking that we're viewing the situation differently.
Case 1. Fine.
Case 2. Extreme but potentially okay if you don't care about losing visitors.
Case 3. There are really subcases here. If there is a reasonable chance that there would be lingering active sessions, then you would have to go through a lot of work to prevent it. I'm talking about the case where a search engine saves a link with a userref in it, and it is not common that there will be prolonged simultaneous user sessions. I think that this scenario is a very common one, probably the vast majority of the cases. My solution, though imperfect, would be sufficient the vast majority of \ the time in those cases. It would certainly be better than the current situation.
Stefan
At 05:29 PM 10/13/2004, you wrote:Right,
Case 1. You don't care about session hijacking. Go ahead and use UserRefArg. There are plenty of appfiles for which this is fine. You may not be able to interpret your logs properly, but the app server works the way you want it.
Case 2. You care about session hijacking, and use session cookies. Witango handles everything for you. But your users with cookies off will keep getting a login prompt.
Case 3. You want to be able to avoid hijacking without session cookies. You need to figure out how to identify each individual user agent, which is not easy. Note it's not enough to just discard and reassign a UserRef, because an "active" one can be passed around while it's still in use. IP address isn't unique. So I think you now need to build your own user identifier, that is passed as the UserReferenceArgument, but that is somehow keyed to a unique user, and distinguishible from another user with the same IP address who is sharing the userreference. Maybe an MD5 hash of the http request. Seems like a lot of work. let us know what you come up with.
On Wednesday, October 13, 2004, at 02:09 PM, Stefan Gonick wrote:
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
=====================================================
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
