thanks all for the thoughts. I remember also that there is special
treatment of the userreference (presumably to avoid predictive
attacks), so I wanted to make sure that I used the server generated
session id, particular for things like load-balancing.
I wanted to do the change in one request to the server to switch a
user of a multi-tenant application, with a common userID (openID for
example) between tenants. I track logins/logout using userreference,
and thought it would be ideal to use a different userref when the
user was logged out of tenant Alpha and into tenant Zebra. Privacy
reasons primarily, since it would be a trifle harder to correlate
comings and goings.
Anyway, I have the user functionality without a changing
userreference, so it's good enough for now.
Bill
William M. Conlon, P.E., Ph.D.
To the Point
2330 Bryant Street
Palo Alto, CA 94301
vox: 650.327.2175 (direct)
fax: 650.329.8335
mobile: 650.906.9929
e-mail: mailto:[EMAIL PROTECTED]
web: http://www.tothept.com
On Mar 15, 2008, at 8:46 AM, Scott Cadillac wrote:
Hi Robert,
That's right, you can't purge a cookie. It can only be given an
empty value or set to expire.
I recall a couple years ago we all had a long investigative thread
on this topic, but of course my fuzzy brain can't remember the
precise outcome just now. But basically I think we found that the
userreference cookie gets some special treatment in the Witango
runtime that prevents tapering with the value (although I think
there was some differences in behavior depending on your version of
tango).
Given all the above, you can use JavaScript to remove the
userreference cookie value (because this happens outside the
witango runtime). This works very reliably. Once the value is
removed, tango does assign a new reference number.
Hope that helps.
Scott,
On Saturday, March 15, 2008 12:31pm, Robert Garcia
<[EMAIL PROTECTED]> said:
Well, there are 2 issues, but keep in mind I am going from memory.
1. You can't gen a userreference, and you can't fake with an MD5,
because witango uses the usereference to tie it to the correct
instance of witango in the group.
2. You can't use purge on cookie scope. If I remember correct, you
have to write the cooke name with zero data. I would test to be sure,
but I am pretty sure you assign cookie value empty string to purge
it.
Then on subsequent request, witango should assign new userref.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Mar 15, 2008, at 8:18 AM, William M Conlon wrote:
I wrote a test taf to see what purging the various scopes would do,
and the USERREFERENCE is unchanged. So to change it, I would need
to generate a new one to replace the cookie from the browser.
What I was looking for was a hook into the witango USERREFERENCE
generation scheme. Anyway, it's just a curiousity, I re-worked my
thinking.
Bill
William M. Conlon, P.E., Ph.D.
To the Point
2330 Bryant Street
Palo Alto, CA 94301
vox: 650.327.2175 (direct)
fax: 650.329.8335
mobile: 650.906.9929
e-mail: mailto:[EMAIL PROTECTED]
web: http://www.tothept.com
On Mar 15, 2008, at 4:17 AM, Robert Garcia wrote:
I think the only way, is to CLEAR the userref cookie, and let
witango gen.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Mar 14, 2008, at 5:48 PM, William M Conlon wrote:
BUT ... userreference WAS received via cookie 'abc'
Bill
On Mar 14, 2008, at 5:46 PM, Ben Johansen wrote:
NO
in the manual
If no user reference number was received
(via the “_userReference” search argument or an HTTP cookie) when
the application file was called, a new number is generated;
otherwise, the
number passed in is returned.
so you clear the cookie and when you call a page without a
userreference arg it will gen a new one
On Mar 14, 2008, at 5:39 PM, William M Conlon wrote:
No, that would not be a NEW userreference, rather the same
userreference that was passed in by cookie.
Here's the flow;
userreference cookie 'abc' is passed to taf
@@user$id and @@user$somedata is known from user reference
'abc'
assign @@request$id == @@user$id
purge user scope variables
get new user refernence 'def'
assign user$id = @@request$id and user$somedata = user's new
data
setcookie
Now on subsequent requests the cookie 'def' is used
Bill
William M. Conlon, P.E., Ph.D.
To the Point
2330 Bryant Street
Palo Alto, CA 94301
vox: 650.327.2175 (direct)
fax: 650.329.8335
mobile: 650.906.9929
e-mail: mailto:[EMAIL PROTECTED]
web: http://www.tothept.com
On Mar 14, 2008, at 5:30 PM, Ben Johansen wrote:
that would be
<@USERREFERENCE>
<@ASSIGN SCOPE="cookie" NAME="Witango_UserReference"
VALUE="<@USERREFERENCE>">.
On Mar 14, 2008, at 5:22 PM, William M Conlon wrote:
I want to tear down a user's session (purging all their
variables) and give the user a new session with new user
variables and a new userreference.
I'll need to <@ASSIGN SCOPE="cookie"
NAME="Witango_UserReference" VALUE="@@request
$newUserReference">.
How do I generate @@request$newUserReference on the server so
I can set the cookie?
I would like the new UserReference to be generated by the
server, rather than by my own home-grown approach, so it isn't
subject to replay cracking attempts. For example if I just
generated a hash from things I new about the user, someone
could conceivably work out the algorithm and generate their
own userreference to hijack a session (admittedly unlikely).
I don't want to know how the server generates a new
userReference -- I just want to get one.
thanks.
Bill
William M. Conlon, P.E., Ph.D.
To the Point
2330 Bryant Street
Palo Alto, CA 94301
vox: 650.327.2175 (direct)
fax: 650.329.8335
mobile: 650.906.9929
e-mail: mailto:[EMAIL PROTECTED]
web: http://www.tothept.com
______________________________________________________________
__________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
_______________________________________________________________
_________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
________________________________________________________________
________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
_________________________________________________________________
_______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
__________________________________________________________________
______
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
___________________________________________________________________
_____
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
____________________________________________________________________
____
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
_____________________________________________________________________
___
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
