oh my gosh... do you know if netscape on mac behaves any better? we have had some bad experiences with it but havent tested it as thoroughly as IE.
----- Original Message ----- From: "Web Dude" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 20, 2003 10:21 AM Subject: Re: Witango-Talk: Loss of Session State Issues. > I gave up on IE on the Mac too. I don't even develop for it anymore. > I heard that Micro$oft is going to be pulling the product > anyway.....YIPPEE SKIPPEE! > > >Hey Robert, > > > >We too have intermitant problems with browsers, but our problems come more > >in the way of javascript not always functioning (we use javascript to make > >sure dates are valid etc, keep the user in bounds) and browsers arent always > >passing the arguments like they should. > > > >Its very odd and disturbing and somewhat frustrating when you have errors > >that disrupt your clients work flow that are because the browser isnt doing > >what its supposed to! > > > >We have found that browsers for macs have a whole slew of problems and that > >mac IE is a terrible product...in some versions some of the intermittant > >argument passing is there so you upgrade and then at the next version thats > >fixed but then its something else. > > > >just wanted you to know were feelin your pain too (; > > > >::growl:: > > > >----- Original Message ----- > >From: "Robert Garcia" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Wednesday, August 20, 2003 2:14 AM > >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 > > > -- > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
