Good questions Robert, I'm also interested in Phil's run down on this behavior, because it is also related to the Session Hijacking issue.
In the meantime I'll give you my interpretation of what I understand, based on what I think you are describing. In one of my previous posts I said "One Witango session-cookie per Window instance", but I should have expanded on that. It should say: "One Witango session-cookie per Window instance, per Domain". Session-cookies, UserReference keys and User Variables are specific to a single Domain address - regardless if they are the same Server or not. Or at least that's the way they should be. If I understand you correctly, you're trying to re-use an existing set of User Variables from one Domain in another Domain on the same Server. Are you saying you have a page link or FORM posting from one site to another, something like: ~~~~~ TAF on www.siteB.com ~~~~ <a href="http://www.siteA.com/some.taf?<@USERREFERENCEARGUMENT>">Jump to siteA</a> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The UserReference value from www.siteB.com should be invalidated for www.siteA.com - if previous versions of Witango/Tango was allowing this, then I think Phil just fixed a major bug. (Another reason I'm glad I don't use <@USERREFERENCEARGUMENT>) If you need to share Variables across domains, then I would investigate the domain.ini file or look at Custom Scope. If all you're doing is trying to preserve your UserReference key for when you come back to www.siteB.com - then this is not how to do it. Either the "Back" action of your browser will return you to a URL with the appropriate <@USERREFERENCEARGUMENT>, or the Session-cookie will send the appropriate key automatically. Session-cookies are Domain specific. The browser handles the fact that all page requests to www.siteA.com gets "KeyA" and all page requests to www.siteB.com gets "KeyB" - no coding involved here. --- Maybe I'm totally misunderstanding what you're doing. If I am, please forgive me. I know you want Phil to answer, but you posted the question publicly - so I responded :-) Hope this helps. Cheers.... > -----Original Message----- > From: Robert Shubert [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 2:56 PM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Loss of Session State Issues. > > > Phil, > > Could you verify the server's response in this situation: > > Step 1. visit website A (get USR assigned in cookie) > Step 2. visit website B (get another USR assigned in cookie) > > Note that both sites are on the same W5 server. Both sites also use > <@USERREFERENCEARGUMENT> > > Step 3. wait an appropriate amount of time, so that your USR on site A > has timed out and cleared, but you are still active on site B. > > Step 4. Jump from site B to site A with > <@USERREFERENCEARGUMENT> to keep > your user variables. > > > Now I think that the W5 server will get an invalid USR from > the cookie, > but a valid USR in the search args. What will the server do? > In my case, > I need the server to realize that there is a valid USR in the search > args, and use it, rather that creating a new USR based on the > fact that > the USR from the cookie has timed out. > > I am seeing a small change in how my servers handle some > functions from > pre 058, since I also understood T2K to prefer USR in > POST/SEARCH/COOKIE > order. > > Thanks, > > Robert > Tronics > > -----Original Message----- > From: Phil Wade [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 1:43 AM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: Loss of Session State Issues. > > I should note here that post args were not searched in T2K or > Witango 5 > prior to the 058 build when the server was trying to locate the user > reference so the T2K server would only look in the cookies and > searchargs. > > The 5.0.1.058 server and above looks for a user reference in the > following > order: > > 1. user reference cookie > 2. user reference search arg > 3. user reference post arg > > Once a user reference is found, the server will no longer continue to > search > for a user reference in the remaining contexts so now the server will > use > the first user reference found and not the last. > > Search arguments can only be up to 255 chars long so if the server > receives > concatenated search arg data from the Browser it just uses > it. For this > reason if you are not using user reference cookies and are relying on > the > user reference search arg it is important to put the user reference at > the > beginning of the search args, not at the end. > > These changes should not have any affect on existing code, except to > make > the delete of the search builders work with browsers that have cookies > disabled (see code below). The delete action passed the user > reference > via > a postarg and always created a new user session in this > instance. This > was > not a big issue as the search builder did not rely on any > user variables > until it was extended by a user. > > Phil > > On 20/8/03 2:31 PM, "Robert Garcia" <[EMAIL PROTECTED]> wrote: > > > The interesting thing about this, is I have a bunch of simple web > admin > > apps with the witango default code, and I haven't had the problem > > before. I think it started around v058 or so. > > > > If I use this code: > > > > <form method=post action="<@appfile>" name=deleteMe> > > <input type=hidden name="_userreference" value="<@userreference>"> > > <input type=hidden name="CommonlabSchedule_uid1" value="<@COLUMN > > "Common.epxLessonSched.rowid">"> > > <input type=hidden name="_function" value="delete"> > > <INPUT TYPE=SUBMIT VALUE="Delete Record"> > > </form> > > > > It seems to work reliably, So I will have to make a lot of minor > > changes. > > > > Robert. > > > > On Tuesday, August 19, 2003, at 08:50 PM, Scott Cadillac wrote: > > > >> Hi Robert, > >> > >> When METHOD=GET is used in an HTML form, like in your > first example, > >> all the > >> FORM element names and values (such as your hidden fields) are > >> automatically > >> concatenated to the value of the ACTION attribute. This > then appears > >> in the > >> address bar of your browser. > >> > >> BUT....if the ACTION attribute already contains other search > arguments > >> (such > >> as <@USERREFERENCEARGUMENT>), then they are sometimes > replaced by the > >> concatenated FORM elements. This is a classic > pain-in-the-*** issue. > >> > >> Your <@USERREFERENCEARGUMENT> is being removed which can > cause you to > >> loose > >> Session state. In the first FORM example, just replace METHOD=GET > with > >> METHOD=POST and it should work. > >> > >> But of course, that doesn't explain your second or third > example, or > >> why > >> your Session-cookie didn't pickup the slack. > >> > >> Are Session-cookies disabled deliberately in your browser? If so, > then > >> checking things like <@USERREFERENCEARGUMENT> for all your > links will > >> be > >> necessary. This includes the TAF files before your actual delete > >> request. > >> > >> Also, checking the value of your USERKEY setting in > witango.ini could > >> be > >> important too. > >> > >> If Session-cookies are supposed to be working, then > something strange > >> is > >> certainly happening. > >> > >> Have you tried seeing what's being passed back and forth > with an HTTP > >> Sniffer of some kind? This will show you exactly the > values are being > >> sent > >> to the Server (both session-cookies and GET and POST arguments). I > >> recommend > >> www.httpsniffer.com > >> > >> Hope this helps. Cheers.... > >> > >> Scott Cadillac, > >> Witango.org - http://witango.org > >> 403-281-6090 - [EMAIL PROTECTED] > >> -- > >> Information for the Witango Developer Community > >> --------------------- > >> > >> XML-Extranet - http://xml-extra.net > >> 403-281-6090 - [EMAIL PROTECTED] > >> -- > >> Well-formed Development (for hire) > >> --------------------- > >> > >> -----Original Message----- > >> From: Robert Garcia [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, August 19, 2003 9:23 PM > >> To: [EMAIL PROTECTED] > >> Subject: Witango-Talk: Loss of Session State Issues. > >> > >> > >> I have been having some problems for a while with some admin pages > that > >> require a login, so session state is paramount. > >> > >> If I use the standard code Witango uses for deleting a record, most > of > >> the > >> time, state is lost: > >> > >> <FORM METHOD=GET ACTION="<@APPFILE>?<@userreferenceargument>"> > >> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" VALUE="<@COLUMN > >> "Common.epxLessonSched.rowid">"> > >> <INPUT TYPE=SUBMIT VALUE="Delete"> > >> </FORM> > >> > >> I have also tried these variations: > >> > >> <FORM METHOD=GET ACTION="<@APPFILE>"> > >> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" VALUE="<@COLUMN > >> "Common.epxLessonSched.rowid">"> > >> <INPUT TYPE=HIDDEN NAME="_userReference" VALUE="<@UserReference>"> > >> <INPUT TYPE=SUBMIT VALUE="Delete"> > >> </FORM> > >> > >> <FORM METHOD=POST ACTION="<@APPFILE>"> > >> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" VALUE="<@COLUMN > >> "Common.epxLessonSched.rowid">"> > >> <INPUT TYPE=HIDDEN NAME="_userReference" VALUE="<@UserReference>"> > >> <INPUT TYPE=SUBMIT VALUE="Delete"> > >> </FORM> > >> > >> > >> However, if I use this code, I never lose state: > >> > >> <p><a > href="<@appfile>?_function=delete&CommonlabSchedule_uid1=<@COLUMN > >> > "Common.epxLessonSched.rowid">&<@userreferenceargument>">Delete this > >> Record</p> > >> > >> Anyone else having these issues, or have any ideas? > >> > >> -- > >> > >> Robert Garcia > >> President - BigHead Technology > >> CTO - eventpix.com > >> 2781 N Carlmont Pl > >> Simi Valley, Ca 93065 > >> ph: 805.522.8577 - cell: 805.501.1390 > >> [EMAIL PROTECTED] - [EMAIL PROTECTED] > >> http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/ > >> > >> > ______________________________________________________________ > _________ > >> _ > >> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > >> > >> > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
