Thank you for the clarification Phil, this is very helpful information. Plus, I think the new strategy you've introduced is a good idea.
Although it's been years since I used the builders, I remember the snippet of code for the Delete POST and I remember having some issue with it. This would have been about the time I started pursuing Session management without relying on <@USERREFERENCEARGUMENT> and such. Coincidence? I think not 8-) Thank you..... 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: Phil Wade [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 12: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
