Hi, I see where your going here, I have a couple of comments on
your question 1. 1. Ironically I am working on a project that uses referrer to pay on referral leads. 2. I have found very few times where REFERER = <@CGIPARAM REFERER> has anything in it. your question 3. 1. this is would be great new feature like a configuration variable like "userRefReset" Ben Johansen - http://www.pcforge.com -Authorized WiTango Reseller http://www.pcforge.com/WitangoGoodies.htm -Authorized Alt-N Reseller http://www.pcforge.com/AltN.htm -----Original Message----- From: Jason Schulz [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 4:49 PM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: RE: Reusing the UserReference key Folks, While session hijacking is a concern, I'd suggest that for most people, the reuse of userref via search engines is a greater problem. This leads me to the following couple of questions. 1) Can the referrer header be put to any use - is there a case where we'd want to maintain the userref for a visitor from an external site? Would it be useful to have witango able to check on a per domain basis that if the referrer is not empty then flush the userref? 2) Can robots.txt be used in a creative way to prevent indexing of dynamic content? 3) If the the user session is expired, can the userref be treated as stale and flushed as well - ie, if it is seen and there is no session that can be associated with it, then a new userref is returned to the user agent. Regards, Jason. | With Imagination www.wi.com.au [EMAIL PROTECTED] | | P 02 9929 9229 M 0411 288 596 F 02 9460 4770 | | Planning, Implementation and Management of Web Applications | > From: "Scott Cadillac" <[EMAIL PROTECTED]> > Organization: XML-Extranet > Reply-To: [EMAIL PROTECTED] > Date: Wed, 6 Aug 2003 15:54:15 -0600 > To: <[EMAIL PROTECTED]> > Subject: RE: Witango-Talk: RE: Reusing the UserReference key > > Sorry, I accidentally hit send before I finished formulating completely what > I was trying to say. > > The issue is all about being granted access to User Variables that you are > not allowed, and this is still possible on that very first hit (before the > redirect). > > Although you are successfully changing the value later, it's the first hit > that concerns me. > > Because everybody writes there code differently, and for different purposes, > a more "global" solution is needed, because I'm not sure this solution will > work for everybody. > > Thank you Atrix, and like I said, you are very very close.... > > 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: Scott Cadillac [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, August 06, 2003 3:33 PM >> To: [EMAIL PROTECTED] >> Subject: RE: Witango-Talk: RE: Reusing the UserReference key >> >> >> I think you're very close Atrix, >> >> You've got the right idea, but I believe if the user is >> hitting the TAF to >> begin with, with something like: >> >> http://www.mydomain.com/userref.taf?_UserReference=F207B47F39D >> AE223F3167B9 >> >> Than your new <@USERREFERENCE> value will be still the old >> key value, even >> though you are redirecting them on the first step. Which is >> the problem. >> >> Remember, this key assignment stuff is happening on the very >> "FIRST" TAF >> request, so it's all done before your file does the Redirect. >> >> But....if your redirect was bouncing them to a non-Witango >> file (HTML) and >> then back again - a new key should be issued because both the >> _UserReference >> argument and session-cookie would be missing. >> >> ....... >> >> >> >>> -----Original Message----- >>> From: Atrix Wolfe [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, August 06, 2003 3:06 PM >>> To: [EMAIL PROTECTED] >>> Subject: Re: Witango-Talk: RE: Reusing the UserReference key >>> >>> >>> ok i think i have a solution to the problem. >>> >>> If you go into this taf with a non-valid user reference, it >>> will assign you >>> a new one. If you keep clicking the link w/ the non-valid >>> user reference, >>> you get a new user ref each time. >>> >>> If you go into this taf with a VALID user ref (by clicking >>> the link on the >>> "Page" part for instance) you keep your user ref as youd expect. >>> >>> best part is, it doesnt have to store a domain scope table of >>> valid user >>> references or anything, it just relies on a user scope >>> variable being set >>> for valid users (: >>> >>> basicly how this would work is this construct would go at the >>> top of all of >>> your tafs with the if and else if and all your code going >> in the else >>> statement. >>> >>> you an also do something cool like changing where it >>> redirects invalid users >>> so you could make them go to your main page or a timeout page >>> or whatever >>> you want. >>> >>> >>> ----- Original Message ----- >>> From: "Ben Johansen" <[EMAIL PROTECTED]> >>> To: <[EMAIL PROTECTED]> >>> Sent: Wednesday, August 06, 2003 1:53 PM >>> Subject: RE: Witango-Talk: RE: Reusing the UserReference key >>> >>> >>>> Ok, some more here. >>>> >>>> I took the copied address into a text editor and changed the >>>> userreference value manually. I opened a new browser pasted >>> the address >>>> with the changed key (to simulate user vars timed out) >>>> >>>> And the user variable was blank and no session cookie was created. >>>> >>>> Interesting :-b >>>> >>>> Ben Johansen - http://www.pcforge.com >>>> Authorized Witango Reseller >>> http://www.pcforge.com/WitangoGoodies.htm >>>> Authorized MDaemon Mail Server Reseller >>>> http://www.pcforge.com/AltN.htm >>>> >>>> >>>> -----Original Message----- >>>> From: Ben Johansen [mailto:[EMAIL PROTECTED] >>>> Sent: Wednesday, August 06, 2003 1:28 PM >>>> To: [EMAIL PROTECTED] >>>> Subject: RE: Witango-Talk: RE: Reusing the UserReference key >>>> >>>> Ok, Now I am confused myself :-) >>>> Ok attached is a new TestAutoCookie.taf >>>> >>>> From page 1 -> page 2 a session cookies is created >>>> >>>> On page 2 there is a new bottom form enter a value and >>> press "to page 3" >>>> Highlight the address >>>> Close the browser window >>>> Open a new browser window and paste the address >>>> >>>> Your user variable will be there but no session cookie. >>>> >>>> Hmmm... >>>> >>>> Ben Johansen - http://www.pcforge.com >>>> Authorized Witango Reseller >>> http://www.pcforge.com/WitangoGoodies.htm >>>> Authorized MDaemon Mail Server Reseller >>>> http://www.pcforge.com/AltN.htm >>>> >>>> >>>> -----Original Message----- >>>> From: Scott Cadillac [mailto:[EMAIL PROTECTED] >>>> Sent: Wednesday, August 06, 2003 1:10 PM >>>> To: [EMAIL PROTECTED] >>>> Subject: RE: Witango-Talk: RE: Reusing the UserReference key >>>> >>>> Hi Atrix, >>>> >>>> Just another follow-up on your testing. And sorry, I >> haven't taken a >>>> look at >>>> Ben's code yet. >>>> >>>> But maybe if a _UserReference value is passed to the Server >>> on the first >>>> request - Witango isn't bothering to issue the >> "Set-Cookie" header, >>>> which >>>> would explain why you don't see the cookies in HTTPLook. >>>> >>>> Just another thought from my rambling brain. And I guess I >>> should just >>>> stop >>>> rambling and do more actual work, eh :-P >>>> >>>> I'm going to get myself in trouble here...I can just feel it.... >>>> >>>> >>>>> -----Original Message----- >>>>> From: Atrix Wolfe [mailto:[EMAIL PROTECTED] >>>>> Sent: Wednesday, August 06, 2003 12:40 PM >>>>> To: [EMAIL PROTECTED] >>>>> Subject: Re: Witango-Talk: RE: Reusing the UserReference key >>>>> >>>>> >>>>> I tested w/ R:Tango 5 (not sure what build or version number >>>>> but I know it >>>>> is pre- the latest secuirty patch), Apache 1.3.24 and >>> windows 2000. >>>>> >>>>> As far as i can see there is no user ref cookie. Im not sure >>>>> the name of >>>>> the cookie so i dumped <@varnames scope='cookie'> and it was >>>>> empty, also >>>>> using HTTPLook i see no cookies (: >>>>> >>>>> Single work station, working localy across 127.0.0.0 >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Scott Cadillac" <[EMAIL PROTECTED]> >>>>> To: <[EMAIL PROTECTED]> >>>>> Sent: Wednesday, August 06, 2003 11:19 AM >>>>> Subject: Witango-Talk: RE: Reusing the UserReference key >>>>> >>>>> >>>>>> Thank you Atrix, >>>>>> >>>>>> Could you also include what version of Witango you tested >>>>> with, OS and >>>>>> Webserver brand? >>>>>> >>>>>> In a serious test environment, it would also be good to >>> see what the >>>>>> session-cookie value is in this scenario (should be the >>> same as the >>>>>> UserReference key). >>>>>> >>>>>> I'm sure this has been discussed on the list in the past, >>>>> but just can't >>>>>> remember the results. >>>>>> >>>>>> Did you use more than one workstation? Just wondering.... >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Atrix Wolfe [mailto:[EMAIL PROTECTED] >>>>>>> Sent: Wednesday, August 06, 2003 12:09 PM >>>>>>> To: [EMAIL PROTECTED] >>>>>>> Subject: Re: Reusing the UserReference key (was: >>>>>>> Witango-Talk: what happens with expired userReference?) >>>>>>> >>>>>>> >>>>>>> Well i just tested it. >>>>>>> >>>>>>> I have a .taf with a results html with this in it: >>>>>>> >>>>>>> <a >>> href="<@cgi><@appfile>?<@userreferenceargument>">test!</a><br> >>>>>>> >>>>>>> what i did was create some links to this with edited user >>>>>>> refs (to simulate >>>>>>> expired user refs since they arent currently valid) >> and yeah, >>>>>>> each one used >>>>>>> the linked user ref as its own...meaning if there was a >>>>>>> search engine or >>>>>>> something that included the user reference argument in the >>>>>>> link, they would >>>>>>> all be using the same session which is no bueno! >>>>>>> >>>>>>> there might be a way to force the client to a new user >>>>>>> reference number. >>>>>>> >>>>>>> if so, at every page you can check to see if >>>>> user$validuser=1. If it >>>>>>> doesnt, force a new user reference number and set >>>>>>> user$validuser to 1 so the >>>>>>> first time someone visits your pages, they are forced to get >>>>>>> a new user ref >>>>>>> number, which would solve this issue. >>>>>>> >>>>>>> One of many solutions people will present, im sure :P >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Scott Cadillac" <[EMAIL PROTECTED]> >>>>>>> To: <[EMAIL PROTECTED]> >>>>>>> Sent: Wednesday, August 06, 2003 10:46 AM >>>>>>> Subject: Reusing the UserReference key (was: Witango-Talk: >>>>>>> what happens with >>>>>>> expired userReference?) >>>>>>> >>>>>>> >>>>>>> After sending my post, and thinking about it.... >>>>>>> >>>>>>> I suppose my answer is probably not right, that the old >>>>>>> UserReference is >>>>>>> reused for a new session. >>>>>>> >>>>>>> In theory, if 10 different people all clicked on the same >>>>>>> Search page links, >>>>>>> which all had the same UserReference key value - and the old >>>>>>> key IS reused >>>>>>> for the new session(s) - then 10 people could be sharing >>>>> the same User >>>>>>> variables. Not good. >>>>>>> >>>>>>> Does somebody have a better answer than me? >>>>>>> >>>>>>> Like I mentioned, I don't personally use >>>>>>> <@USERREFERENCEARGUMENT> in my apps >>>>>>> and strictly rely on the session-cookie. So the above >>>>>>> wouldn't happen to me, >>>>>>> and I don't have an opportunity to test my own answer. >>>>>>> >>>>>>> Any feedback anyone??? >>>>>>> >>>>>>> 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: Scott Cadillac [mailto:[EMAIL PROTECTED] >>>>>>>> Sent: Wednesday, August 06, 2003 11:34 AM >>>>>>>> To: [EMAIL PROTECTED] >>>>>>>> Subject: RE: Witango-Talk: what happens with expired >>>>> userReference? >>>>>>>> >>>>>>>> >>>>>>>> Hi Roland, >>>>>>>> >>>>>>>> As long as the VariableTimeout has expired by the time of >>>>>>> the new page >>>>>>>> visitor (with the old link), then the old User >> Variables are >>>>>>>> gone - and new >>>>>>>> ones are assigned as needed. >>>>>>>> >>>>>>>> I think, but not 100% sure, that the old UserReference key >>>>>>>> value in the old >>>>>>>> link is actually reused. This particular question >>> is tough to >>>>>>>> answer because >>>>>>>> for myself, I don't use <@USERREFERENCEARGUMENT> and >>>>> just rely on >>>>>>>> session-cookies, which means your scenario would never >>>>>>> present itself. >>>>>>>> >>>>>>>> It is when the VariableTimeout period has not expired yet >>>>>>> (default 30 >>>>>>>> minutes), that a Security issue is introduced >> where the new >>>>>>>> visitor can be >>>>>>>> given access to someone else's User Variables. >> This is known >>>>>>>> as Session >>>>>>>> Hijacking. >>>>>>>> >>>>>>>> But, with all that said, your scenario I think is less >>>>> problematic. >>>>>>>> >>>>>>>> Your concern is about when a SearchBot hits your >>> site, and is >>>>>>>> automatically >>>>>>>> granted a <@USERREFERENCE> key. This key value is >>> then stored >>>>>>>> as part of >>>>>>>> your site links for a search engine - which is >> then exposed >>>>>>>> to anonymous >>>>>>>> users. >>>>>>>> >>>>>>>> In theory the SearchBot is not logging in to secure pages >>>>>>>> with a password, >>>>>>>> and is typically not trying to do on-line purchases - so I >>>>>>>> would think there >>>>>>>> is very little to hijack. Especially given the fact >>>>> that a case for >>>>>>>> hijacking is very remote here. >>>>>>>> >>>>>>>> In theory, in your code, any User Variables you assign to >>>>>>>> anonymous visitors >>>>>>>> on the public side of your pages are relatively >> non-critical >>>>>>>> - which is all >>>>>>>> a SearchBot would be granted, or any other public >>> visitor who >>>>>>>> has not logged >>>>>>>> in yet. >>>>>>>> >>>>>>>> Of course that is just theory because I don't really know >>>>>>> what you're >>>>>>>> assigning your public anonymous visitors, with respect to >>>>>>>> Variables or your >>>>>>>> VariableTimeout setting. >>>>>>>> >>>>>>>> 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: Stefan Gonick [mailto:[EMAIL PROTECTED] >>>>>>>>> Sent: Wednesday, August 06, 2003 11:05 AM >>>>>>>>> To: [EMAIL PROTECTED] >>>>>>>>> Subject: Re: Witango-Talk: what happens with expired >>>>>>> userReference? >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm pretty sure that the Witango server starts a new >>>>>>>>> user session if the user reference has expired. >>>>>>>>> >>>>>>>>> Stefan >>>>>>>>> >>>>>>>>> At 09:47 AM 8/6/2003 -0700, you wrote: >>>>>>>>>> when you have a project and the company's IT manager >>>>>>>>> personally refuses >>>>>>>>>> cookies, he writes it into the job spec that the >>> site work >>>>>>>>> for people who >>>>>>>>>> hate cookies. ain't that nice? >>>>>>>>>> >>>>>>>>>> On Wednesday, August 6, 2003, at 09:36 AM, Bill >>> Conlon wrote: >>>>>>>>>> >>>>>>>>>>> Yet another reason to use <@USERREFERENCECOOKIE> >>>>>>>>>>> >>>>>>>>>>>> when a bot cruises through a site and each link has a >>>>>>>>> userReference=xxx >>>>>>>>>>>> URL argument, it stores those along with the >>> stable URL. >>>>>>>>> What happens >>>>>>>>>>>> when someone comes back to that exact URL, >>> userreference >>>>>>>>> and all, after >>>>>>>>>>>> the session variables have expired? >>>>>>>>>> >>>>>>>>> >>>> _____________________________________________________________ >>>>>>>>> ___________ >>>>>>>>>> TO UNSUBSCRIBE: Go to >> http://www.witango.com/maillist.taf >>>>>>>>> >>>>>>>>> ======================================================== >>>>>>>>> Database WebWorks: Dynamic web sites through database >>>>> integration >>>>>>>>> http://www.DatabaseWebWorks.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 >>>>>>> >>>>>> >>>>>> >>>>> ______________________________________________________________ >>>>> __________ >>>>>> 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 >>>> >>>> >>> ______________________________________________________________ >>> __________ >>>> 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 ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
