State, and stateless.
By stateless, this means the following:
Stateless:
You hit a website. The server serves you the page, then disconnects you from the server. The server does not keep track of you in any way. That's why when you hit refresh on your browser, the server just sends you the same page. The web server doesn't remember giving you the page 2 seconds ago, that's why the server will continuously give you the page as if you are a new visitor to the site. The same goes if you stay on the same site, but change pages. The server doesn't know if you are the same person from the previous page or not.
State:
On a LAN, when you're running an enterprise server application. The client machine logs onto the server. By logging on, the server keeps your session, or state alive, and periodically pings your machine to make sure you're still connected. So, if you pull up a report in AccPac, then try to pull up the same report 2 seconds later, the application will return "You last accessed this report recently. Are you sure you want to re-generate this report again?" On a LAN, the server keeps track of you by your user account on the server. Also, the server will keep track of you by your DHCP assigned IP address which is unique to the network. Provided it's set up this way. The server will also keep track of you by the name of your computer as well. These methods aren't available over the internet because of major security issues, and disk space. Therefore web servers don't keep track of users automatically.
Rick Sanders
Thank you again Ian,
In addition - anybody remember that statement "the web is stateless"?
It's all about whether or not the Witango server (or any web platform) can tell the difference
between two different people over the Internet - it can't.
As far as Witango (or any web platform) is concerned, because of the session ID in the Search
Engine link - the two users are the same person, thus the shared session.
Removing session information from a URL argument string (<@USERREFERENCEARGUMENT>) is your
first best step in tackling the problem - then relying on session-cookies to uniquely
identifying you over the Internet (provide "state") is the next best step.
The Internet is not perfect and can never be 100% secure - so you have to strive to provide the
best possible solution and security at all times.
Session-cookies are also not perfect - but they are the best option you have.
To understand web programming, you have to understand "state".
Does anybody not know what I mean by "state" in context of the web?
-----Original Message----- From: "Ian Daniel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Wed, 13 Oct 2004 11:10:41 -0700 Subject: RE: Witango-Talk: Cookies
Ahh ..
When your User1 came, supplied a UserReferenceArgument ("URA"), the server, if Witango 5, checked for a UserReferenceCookie ("URC"). Finding none, it assumed the value of the expired URA, seeing no reason why it should be rejected.
Note: I have not tested the above scenario with the very latest versions of Witango. I am making a rather bold assumption that the above scenario .. which was true ... is still true. I haven't seen anything which leads me to believe otherwise.
User 2 came along with the same URA, and having no URC, the server obliged and allowed the second browser to share the now current variable store created by User1.
Does this help? The "error" may be in thinking that the server would not "honor" the expired URA by establishing a session with the value of that argument.
tks, Ian
-----Original Message----- From: Stefan Gonick [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 10:37 AM To: [EMAIL PROTECTED] Subject: RE: Witango-Talk: Cookies
Hi Ian,
Thanks for joining in. Let's re-examine your scenario:
User 1 clicks on the link and the Witango server detects that the session was expired and starts a new session assigning userreference A.
A moment later User 2 clicks on the link and the Witango server detects that the session was expired and starts a new session assigning userreference B.
It seems to me that the server would assign two different userrefs to those users rather than them sharing one. I doubt that it stores some connection between the old expired userref and the newly generated one. The rest of your scenario would not exist if I'm right.
So, how does this really work?
Stefan
At 01:26 PM 10/13/2004, you wrote: >Ok .. take a break, Scott ... I'll try this on .... > >Stefan .. you are correct in what you have said, but consider this: > >If two independent users then find that spidered, expired session ... and >each independently come to the site, using the same UserReferenceArgument >from the spidered, expired session, and each begin a shopping cart >experience, can you imagine the result? > >Let's see .. I'll place some items in the basket .. you do too. We both >head to the checkout .. I put the shipping address, just in the nick of time >overwriting yours which you just posted, but I then go looking for my credit >card while you complete the order. We then use your credit card to ship an >order to me. > >Are we having fun yet? > >o[;-) > >-----Original Message----- >From: Stefan Gonick [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 13, 2004 10:17 AM >To: [EMAIL PROTECTED] >Subject: Re: Witango-Talk: Cookies > > >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 > >______________________________________________________________________ __ >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
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
