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
