|
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 -----
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
|
