Hey Scott,
If anyone bans you from the list because of this, I'll personally vouch for you!
Yes, I do understand web programming. When I develop sites, I have to use cookies. There's just no other way.
Yes, IP addresses isn't a great solution, but my idea was to combine and compare both an IP address and <@USERREFERENCEARGUMENT> together. What do you think the odds are of 2 people hitting your site using the same session ID, and from the same IP from a search engine. It's no impossible, but highly unlikely.
And yes, people can send forged packets, spoof IP addresses, and re-route themselves using a proxy. Let's not forget the online services such as megaproxy.com etc...
I merely suggested an alternative to a problem that's all. Session cookies are the best way to keep unique sessions, and it's how I program personally. I've actually been using cookies for a very long time, and been web programming for a very long time as well.
Rick
I'm sorry Rick,
But at the risk of alienating people, being removed from the Witango-Talk list, and potentially
losing business as an independent contract developer...
Rick, you don't understand programming for the web - you just don't get it.
Sincerely,
Scott Cadillac, XML-Extranet ~ 403-254-5002 ~ [EMAIL PROTECTED] ------------ Well-formed Programming in C# ASP.NET, Witango and XML For Hire ~ http://xmlx.ca/forhire ------------ IExtranet ~ http://IExtranet.net ------------ Weblog ~ http://xmlx.ca Forums ~ http://forums.xmlx.ca Knowledge Base ~ http://kb.xmlx.ca ------------ P.O. Box 69006 RPO Bridlewood SW Calgary, Alberta Canada T2Y 4T9
-----Original Message----- From: "Rick Sanders" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Wed, 13 Oct 2004 13:37:51 -0400 Subject: Re: Witango-Talk: Cookies
Exactly!
Hence why <@USERREFERENCEARGUMENT> & tracking the IP address together are probably the best way to define unique sessions. Assign the user's IP address to a user variable too. So, if someone comes in from a search engine with an expired <@USERREFERENCEARGUMENT>, but there's no IP address for that session, then you know it's expired.
It's more work, but it's worth it to not have to use cookies.
Rick Sanders
> Case 1: spidered session has expired. Someone hits the link with the > expired > userref and has cookies off. I believe they just revived that session - > started another with the same id. > > Case 2: (real) Person on a witango site that uses userrefarg. Copies link > and posts it to a group. Everyone in that group now has direct access to a > live session. That session stays live as long as someone in the group it > hitting it within the timeout period. Sort of a flashmob session. > > > On 10/13/04 10:17 AM, "Stefan Gonick" <[EMAIL PROTECTED]> wrote: > >> Hi Scott, >> >> Forgive me if I find this explanation less than satisfying. :) >> If sessions typically expire after 30 minutes of inactivity, >> then spidered sessions would extremely likely have expired >> by the time someone has clicked on the link. Am I missing >> something here? >> >> Stefan >> >> At 01:10 PM 10/13/2004, you wrote: >>> Hi Stefan, >>> >>> Who knows if it ever expired? >>> >>> Personally, I think the bug is using <@USERREFERENCEARGUMENT> period. >>> >>> Just remove it - and more than one problem is solved. >>> >>> >>> -----Original Message----- >>> From: Stefan Gonick <[EMAIL PROTECTED]> >>> To: [EMAIL PROTECTED] >>> Date: Wed, 13 Oct 2004 12:58:56 -0400 >>> Subject: Re: Witango-Talk: Cookies >>> >>>> What kind of factor can lead to the resurrection of an expired session? >>>> >>>> Stefan >>>> >>>> At 01:04 PM 10/13/2004, you wrote: >>>>> Hi Stefan, >>>>> >>>>>> I STILL don't understand why UserReferences from a week ago should >>>>>> lead to session hijacking. Wouldn't this UserReference have expired >>>> a >>>>>> long >>>>>> time ago? Wouldn't that result in creating a new UserReference? If >>>> not, >>>>>> wouldn't this be considered a bug? >>>>> >>>>> There can be more than one factor involved with why this can happen, >>>> and >>>>> therefore hard to >>>>> eliminate. >>>>> >>>>> Keep in mind this problem plagues more web development platforms than >>>> just >>>>> Witango. >>>>> >>>>> This is more of a flaw in the Internet "architecture" brought about by >>>> the >>>>> addition of >>>>> user "convenience" - but that convenience is superseded now by >>>> security >>>>> concerns. >>>>> >>>>> Basically, in my opinion - just don't use <@USERREFERENCEARGUMENT> for >>>> any >>>>> reason. >>>>> >>>>> Hope this helpful. Cheers.... >>>>> >>>>>> Stefan >>>>>> >>>>>> ===================================================== >>>>>> Database WebWorks: Dynamic web sites through database integration >>>>>> http://www.DatabaseWebWorks.com >>>>>> >>>>>> >>>> _______________________________________________________________________ >>>>>> _ >>>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>>>> >>>>> >>>>> ______________________________________________________________________ >>>> __ >>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>>> >>>> ===================================================== >>>> Database WebWorks: Dynamic web sites through database integration >>>> http://www.DatabaseWebWorks.com >>>> >>>> _______________________________________________________________________ >>>> _ >>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> >>> >>> _______________________________________________________________________ _ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> >> ===================================================== >> Database WebWorks: Dynamic web sites through database integration >> http://www.DatabaseWebWorks.com >> >> _______________________________________________________________________ _ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> > > > ----------------------------------------- > Roland Dumas > Roberts Information Services > 310 W. Bellevue Avenue > San Mateo CA 94402 > 650-347-1373 > 415-412-9300 (cell) > [EMAIL PROTECTED] > SMS: http://new.servqual.com/html/sms.tml > > > _______________________________________________________________________ _ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >
_______________________________________________________________________ _ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
