list, This is a repeat of my contribution to the session-cookie vs. userreferenceargument thread (Reusing the UserReference key).
If you want your users to be able to have multiple window instances accessing the site, take a look at the article I have on Scott's site: "Persistent login from anywhere on a web site" http://xml-extra.net/webpage.xmlx?node=95 By using a persistent cookie (one that expires on a future date rather than with the session), you can have a single user instance on the server, no matter how many browser instances are active. One drawback is that there can be inconsistency between the browser instances. E.g., I'm looking at a threaded discussion list in two browser instances, and I add comment in the first. Unless you have a mechanism to refresh the second, it will be inconsistent. Another approach is to keep track of which users are logged in, and only allow them a single browser instance. >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 > Bill Conlon To the Point 345 California Avenue Suite 2 Palo Alto, CA 94306 office: 650.327.2175 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/maillist.taf
