Hi Robert, Your scenario does shed more light here, thank you.
> Use the bookmark to go back, sometimes a new reference is created, > which means the cookie was not read correctly. This happens on my > servers intermittently. The behavior above will be dependant on whether or not you "go back" from within the same Browser Window instance or in a new Window instance. Bookmarking typically has nothing to do with cookies (of any kind), and session-cookies are managed by the currently open Browser Window instance. One Witango session-cookie per Window instance. Bookmarks typically only save search argument names and values. -------- Note: By window "instance" I mean, a browser window launched from scratch, like from "Start / Programs / Internet Explorer" (on Windows). Browser Windows subsequently launched from the first Window of the instance (like from a <A HREF=""></A> hyperlink) are actually part of the same instance because they inherit the session-cookie(s) collected by the earlier window(s). -------- A new Browser Window instance typically initializes a new UserReference key because a new instance does not contain any session-cookies. Trying to re-use a previous _UserReference argument value was a topic of another big discussion thread we had on the List recently - which we never got resolved completely. Trying to re-use a previous _UserReference argument value is also known as Session Hijacking, and shouldn't be relied on as a means to maintain Session state. In fact, for me, this is the pivotal point on why I do "NOT" use <@USERREFERENCEARGUMENT> in my applications - and instead rely on Session-cookies. Because session-cookies are not captured, bookmarked or easily visible to users. If you click your bookmark within the same Browser Window instance (the same instance used to save the bookmark to begin with), then in theory it should work. But maybe this behavior is Browser specific - what browser are you using during this testing? Let us know. Hope this helps a little.... > -----Original Message----- > From: Robert Garcia [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 9:56 AM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: Loss of Session State Issues. > > > I am not having the problems with the post method, and the > userreference as a post arg. I meant that the old code is > intermittent, > and does not work on cookie enabled browsers. > > For instance go a page that you set up that displays your > userreference. Then bookmark the page. > > Use the bookmark to go back, sometimes a new reference is created, > which means the cookie was not read correctly. This happens on my > servers intermittently. I protect by using userreference in > every link, > not totally relying on cookies. > > Robert. > > On Wednesday, August 20, 2003, at 08:13 AM, Scott Cadillac wrote: > > > Hi Robert, > > > > Sorry you're still having problems. > > > > Just a guess, but is it possible your FORM posting sometimes uses an > > absolute address? That might be an alternate address or IP > for your > > Server? > > This could cause a different UserReference key to be issued. > > > > Typically everyone uses something like ACTION=<@APPFILE>, which is a > > relative address, which is good - but I thought it was worth asking. > > > > Also, just another guess, are you outputting a custom HTTP > header (via > > local$httpHeader)? If so, unless the contents is precisely > formed, this > > could contribute to Witango not properly assigning your > UserReference > > key. > > > > If everything still looks like it should, then I would > suggest setting > > up a > > test environment where you track your UserReference key > with an HTTP > > sniffer > > tool (or at least debug on every page) and see if you can > reproduce > > this odd > > behavior. > > > > The trick is seeing if your UserReference key value has suddenly > > changed or > > is missing altogether - either from the > Witango_UserReference cookie > > or the > > _UserReference arguments. > > > > I know, doesn't help much, but here's hoping. Cheers.... > > > > Scott Cadillac, > > Witango.org - http://witango.org > > 403-281-6090 - [EMAIL PROTECTED] > > -- > > Information for the Witango Developer Community > > --------------------- > > > > XML-Extranet - http://xmlx.ca > > 403-281-6090 - [EMAIL PROTECTED] > > -- > > Well-formed Development (for hire) > > --------------------- > > > > > >> -----Original Message----- > >> From: Robert Garcia [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, August 20, 2003 3:14 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: Witango-Talk: Loss of Session State Issues. > >> > >> > >> The only thing I would add to that phil, is that I have the problem > >> with browsers when I am sure cookies are not disabled with the old > >> delete code, and it is intermittent. Mostly not working, sometimes > >> working. > >> > >> I am using the default setup on the server for userkey, and do no > >> altering of cookies and such. > >> > >> Thank you for the info on how the newer servers look for > >> userreference. > >> > >> Robert. > >> > >> On Tuesday, August 19, 2003, at 11:43 PM, Phil Wade wrote: > >> > >>> 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 > >>> > >>> > >> > >> -- > >> > >> 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 > > > > > > -- > > 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
