understading cookies with some open ended ramblinig.

These are my thoughts on cookies, and sessions as I am learning them. If you have something positive and instructional to say to help me understand how they are used, I would love to hear it. So far, I've learned that cookies are sent with every path qualified window instance of a browser back to the site that recoreded them. A document root based cookie with a path like: http://www.sitename.tld/ can identify a user as logged in to the site, it can't identify the browser window instance. So, only using the session information, a second browser window will get all the same information as the first browser window from the site, and so multiple accesses to the same applications on a site cannot have different states, without the accesses interfering with each other. In thinking about this, in a sort of OOP way, the browser instance, (including all its windows), is the parent class, being instantited by one user. The assumption is made that only one user is using the computer at a time. The user at the screen, having opened the browser instance, is identified by his/her cookie session. This works because even in Windows anymore, each user now has their own directory with their own cookies. If you let someone use your computer without shutting down the browser, OH Well! This applies to session cookies with a session id in it. A timed cookie with a short duration time is more secure, as it expires whether the browser session is closed or not. that leaves the children of the browser to be each individual window. The only ways to individually assign identities to a window instance, i.e. to have mulitple windows in different states on the same application from the same user using the same cookie session id, is to use an additional variable in the form on a page. This basically says that cookie sessions are only good for form usage. Now, GET and POST sessions are usable for different sessions simultaneouly being used by the same user on the same machine, however: GET sessions can be hijacked pretty easily. POST sessions must be used only on pages with submit buttons. PAINFUL. another way is to use dynamic directory naming, essentially putting the session in the directory name. Once this is observed by 3rd parties, it is no more safe than GET sessions. In rereading my post, I thought of an additional way, that WOULD allow session cookies with session ID in them to identify individual windows from a single user. Make the directory path for the User be a second distinct MD5 number, immediately below the site root: http://www.somesite.ltd/long-md5-number/real/path/to/applications/application. Now, make the path for the cookie be: http://www.somesite.tld/long-md5-number/ Also make a cookie that just goes off the doc root: http://www.somesite.tld/ the cookie off the root, determines the user, and the cookie off the pseudo path determines the browser window. Of course, the user can cut and paste the doc path and name to an additional window and access the same application from two windows, but who cares? Your logic should be treating that as simply the use of the back button, like in a browser like Opera that caches everything. You can decide whether to honor the out of sequence request, or just give them what's in the most current state of their application window. BUT their normal usage will give them completely different accesses to the same different application, without putting their session number in the clear, in the URL. It doesn't stop network sniffing attacks, but it does stop relay log attacks and emailing/proxy attacks. The above requires mod_rewrite directory rewriting, which is a learning curve in itself. The same thing could be done with a GET value. This is probably how bigger applications like AMAZON, etc are doing it. User login in validation in the session cookie, Window instance in the GET parameter. I do seem to remember LONG numbers in the GET part of the URL of most large site accesses I've done lately.