Hmmm.... Interesting question Jon. The Help documentation is not very specific. It does just say 'search arguments' but I also have found this reference used ambiguously in other places.
Jon, you've opened the door of doubt in my mind now, although I'm 99% certain that it is true - it has been awhile since I used this method (because I use suggestion 2.), so I'm reluctant to say that it is fact. Until I can find some time to test this (by writing some code - which excludes HTTP Cookies that may compromise the testing), I will apologize for possibly misleading anyone. My rebel ways often get me into hot water - but it's always more fun this way:-) Cheers... ----- Original Message ----- From: "Jon Grieve" <[EMAIL PROTECTED]> To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]> Sent: Friday, May 10, 2002 8:42 AM Subject: RE: Witango-Talk: Silly Userreferance argument > Scott, > > Are you sure you can pass "_UserReference" in Post Arguments, as shown > below? I understood it *had* to be a Search Argument; that Witango was > effectively hard-coded to <@SEARCHARG> instead of <@ARG>. > > I'm sure I got this nugget of information off the list here, as I enquired > about hiding them in hidden post fields a long while ago... maybe it > changed in SP1..? > > Jon > > > > > -----Original Message----- > From: Scott Cadillac [mailto:[EMAIL PROTECTED]] > Sent: 10 May 2002 4:08 > To: Multiple recipients of list witango-talk > Subject: Re: Witango-Talk: Silly Userreferance argument > > > Hi Dan, > > > I had at least one incident where clicking on a links where they were > > different ended up bring up someone else's information. > > > > So which is best to use or are their times when one is needed instead of > the > > other? > > In the case where you have to be especially careful that a user does not > give away their _UserReference argument value, when they pass a URL to > someone else - I have two suggestions that may help. > > 1.) - For <FORM> Posting, use a hidden field, like so: > > <form method="post" action="<@APPFILE>"> > <input type="hidden" name="_function" value="LookUp" /> > <input type="hidden" name="_UserReference" value="<@USERREFERENCE>" /> > <input type="text" name="SomeField" value="" /> > </form> > > Although the above doesn't help with simple HyperLinks, you could replace > some crucial links with something like the following - to keep the > _UserReference value out of the browser address bar: > > <form method="post" action="<@APPFILE>?_function=LookUp&ID=12345"> > <input type="hidden" name="_UserReference" value="<@USERREFERENCE>" /> > <input type="submit" value="Open List" /> > </form> > > Bulky I know - but often Security is more important than style. > > > 2.) - If you are writing for a controlled Intranet environment, where the > organization has specified the Browser (and it's settings), such as the case > of most businesses that can afford their own Intranet Applications. You can > just not include the <@USERREFERENCE> Metatags at all, and just rely on > 'per-session' cookies to pass the _UserReference value - and maintain the > User's Session. Then your _UserReference is never exposed in the Browser > address bar, and is not included in URL copying or bookmarking. > > For all my private Intranet (and Extranet) Applications, I haven't used > <@USERREFERENCE> for over 2 years and it hasn't been a problem. Of course I > provide instructions to users about these settings, which can be found here: > > http://help.plusinternational.com/html/Browser_Settings.htm > (Above URL may word-wrap) > > How 'per-session' cookies work with Witango: > """"""""""""""""""""""""""""""""""""""""""""" > -- When someone requests a TAF file for the first time - Witango issues an > HTTP Header with the TAF content (regardless of what kind of browser they > have) that looks something like the following: > > HTTP/1.1 200 OK > Server: Microsoft-IIS/5.0 > Date: Fri, 10 May 2002 14:35:03 GMT > Connection: close > Content-Type: text/html > Set-Cookie: Tango_UserReference=11D62D02C68786E53CDBDA97; path=/ > > The above is a 'per-session' cookie because it does not contain a > 'expires=DATETIME' property. These kinds of cookies are not written to the > harddrive (only stored in memory) and are destroyed as soon as the user > closes their main browser window. > > Now, after the user has received their first TAF - every subsequent request > they make back to the same Witango Server will include something like > following in their HTTP Request Header: > > GET / HTTP/1.1 > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, > application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, > */* > Accept-Language: en-us > Accept-Encoding: gzip, deflate > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; > Q312461; .NET CLR 1.0.3705) > Host: xml-extra.net > Connection: Keep-Alive > Cookie: Tango_UserReference=11D62D02C68786E53CDBDA97 > > As you can see - their UserReference value is included. From what I > understand, Witango will first check to see if a _UserReference argument is > present, if not, then it checks for the above - if found, this value is used > for maintaining Session State (a.k.a User Scope). It will be the same value > found in your <@USERREFERNCE> Metatag. > > Like I said, I've been doing this for years in the private 'controlled' > environment of my applications and haven't had a problem. > > The one exception to the above, is the circumstance where you provide a > dynamic link to a secure document (like MS Word) and the Word content is > delivered with a TAF address. I found that unless the link includes the > <@USERREFERENCEARGUMENT> - sometimes the link won't open. I think this more > a bug with certain versions of MSIE than anything else. > > Here is some additional information on Session Cookies: > http://www.netscape.com/newsref/std/cookie_spec.html > (Above URL probably won't word-wrap) > > Note: In the absence of a <@USERREFERENCE> value, and the User has > 'per-session' cookies disabled, Witango will issue a new, > Set-Cookie: Tango_UserReference=1212F5DB16A70CFA3CDBDD65; path=/ > value - when one is not found on the current Request, which is why Users > have to keep logging on with each new page request. > > Hope I provided some insight. Cheers... > > Scott Cadillac > http://xml-extra.net > [EMAIL PROTECTED] > > VP, Research and Development > Plus International Corp. > 604-460-1843 > [EMAIL PROTECTED] > http://www.plusinternational.com > > Vancouver, BC, Canada > > Does your company have an Enterprise Information Portal? Check out Salsa at > www.plusinternational.com/flash/salsa.htm > > ----- Original Message ----- > From: "Dan Stein" <[EMAIL PROTECTED]> > To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]> > Sent: Friday, May 10, 2002 4:03 AM > Subject: Witango-Talk: Silly Userreferance argument > > > > Seems I have sometimes used Userreference and sometimes userreferance > > argument in my growing application. > > > > I would think it is important to be consistent and use one or the other > but > > not both. > > > > I had at least one incident where clicking on a links where they were > > different ended up bring up someone else's information. > > > > So which is best to use or are their times when one is needed instead of > the > > other? > > > > Should I change them all to one or the other? > > > > Why do we have both? > > > > Dan > > > > -- > > Dan Stein > > Digital Software Solutions > > 799 Evergreen Circle > > Telford PA 18969 > > 215-799-0192 > > 610-256-2843 > > Fax 413-410-9682 > > FMP,Tango, EDI,SQL 7 > > [EMAIL PROTECTED] > > www.dss-db.com > > > > > > ________________________________________________________________________ > > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > > with unsubscribe witango-talk in the message body > > > > ________________________________________________________________________ > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body > ________________________________________________________________________ > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body > ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
