The scenario you describe is something that is already being handled
by our code. I don't think that anyone is concerned about that. The
problem is when you don't have a login situation but still need to maintain
your session and don't want hijacking.
It seems to me that the server should do it's best to recognize that
an old UserRef is expired and not reuse it.
Stefan
At 05:10 PM 10/13/2004, you wrote:
Hey Stefan,
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.
Not sure if you caught this but you can make this happen easily. Let's say you have a login screen and that after logging in, you set a variable user$username that you can count on being not empty as long as the user is logged in.
At the top of every taf file that requires the user to be logged in, you put an if action that says "if @@user$username is empty", and inside that if action, you put a results html that does a redirect to the login screen and after the results html you put a return.
This will make it so if someone tries to go into a "logged in only" page with an invalid or expired user key, that they will get booted back to the login screen.
Personaly, I dont think the server should handle this for us. As it is now, we can control the behaviour of these things. It is our choice.
If the server handled this for us, we would be locked into one behaviour and may not be able to do what we want in some situations.
It's better for the server to be more dynamic and give us choices then to tell us what we can and can't do dont you think?
- ----- Original Message -----
- From: Stefan Gonick
- To: [EMAIL PROTECTED]
- Sent: Wednesday, October 13, 2004 1:55 PM
- Subject: Re: Witango-Talk: Cookies
- 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
________________________________________________________________________ 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
