Tod Harter <[EMAIL PROTECTED]> wrote on 26/04/2005 20:41:47: > The problem, I THINK, is that his browser is NOT sending back the > cookie.
What exactly do you mean by 'sending back'? > This means every time the server > handles a request it creates a NEW session, thus a new file... Now that > COULD be caused by the server not SETTING > the cookie in the 1st place, that I couldn't say! The cookie is definately being set... I just checked that. > It also seems ODD that the browser doesn't get a new session when it > hits an old page. THAT makes me think the real problem is the URL the > cookie is set for. If its set for just the individual page then this is > exactly what would happen, you'd have an independent cookie (and > session) for each URL (IE for each page). After trying to monitor the cookies, this is what I found: 1. First visit to site -> new session file created -> new cookie created (expirey time seems to be set to the session creation time, and path is set to the path of the page the cookie was set from) 2. Subsequent page requests -> no new session files -> no new cookies 3. login (setting session variables) -> no new session files -> no new cookies 4. Subsequent page requests -> no new session files -> no new cookies 5. Logout (session:invalidate) -> session file removed - > cookie still exists in browser!!! 6. Subsequent page request -> new session file created -> new cookie set (again, exriry time is set to current date and path is set to the path of the page the cookie was set from) 7. quit browser and reopen -> all the session files still exist I hae also noticed that if when I first visit the site, I enter from a page other than / (the home page) a cookie gets set with the path value set to that page location. As I then navigate through the site, new cookies (and session files continue to be created (one for each new page I visit) until I visit the home page (at which point a cookie gets set with the path value set to '/'). From then on, no new cookies get set and no new session files get created. I then tried deleting all cookies except for the one set at / and one at another location... no new session files and no new cookies get created. I then deleted the cookie set at /... now new session files and cookies get set for every new page request (except for page requests at the location of the other cookie I left behind. OK. So that's all probably a bit hard to understand. But basically it looks like the cookie gets set for a the particular URL of the page you are on. This is fine if the first page you visit is the root page (home page) because it seems that the validity of this cookie cascades down the web tree, making all other page requests part of that session. However, if you start off at a different location (ie. not the home page, or any other page located at /), you will end up with a session file for each location. - A bit pointless - not really the idea of a session (in my understanding of it anyway) > Otherwise it sounds to me like his file session store is working the way > you would expect. Every session has its own file and if you delete one > then the Apache::Session logic happily creates a new empty one for you, > and depending on the exact way the code is designed on the server side > you may get a new sessionid and cookie to boot, I just don't have the > code in front of me right now to look and see. Yes I agree. this seems like it is functioning as it should... removing the session file and creating a new one (and a new cookie to go with it). So I think the problem is definately in the cookie! Plus. Should the cookies not get deleted when you exit the browser? Otherwise, as I have just found out. Quiting the browser and re-opening it does not invalidate your session and log you out!!!! > Michael Nachbaur wrote: > > [EMAIL PROTECTED] wrote: > > > >>>> Running <session:invalidate> causes the current session file to be > >>>> deleted. > >>> > >> > >>> Hmmmm, the _file_? It should delete the session in the sessions file, > >>> but not the file itself.... That would cause the loss of all > >>> sessions... > >> > >> > >> Thats right. The users session file gets physically removed from the > >> file system and subsequent page requests cause new files to be > >> created on the filesystem (one for each new page request). > > > > > > This is a symptom of the "File" datastore, rather than the default > > "DB_File" datastore that I believe Kjetil is using. The File > > datastore is easier to purge older sessions because you can take a > > look at the mtime of the file to delete it; it also helps with > > debugging a site, because you can see exactly which sessions exist. > > > > However, it also introduces a rather nasty problem of thousands of > > files in a directory for popular sites. I believe this is where some > > of the confusion came in. > > > >> I am not specifically telling the browser to delete cookies in my > >> script, I assume that session:invalidate does this as part of its > >> invalidation process? (when I say 'deleting the browser cookies' I > >> mean I have manually gone into the browser preferences and selected > >> 'delete cookies' in an attempt to stop new files being generated on > >> the filesystem). Although this had no effect and the session folder > >> continued to fill up with new files. > > > > > > I tend not to trust that feature of most browsers, as it doesn't work > > as I expect it to. I haven't sat down and performed any rigorous > > tests, but usually deleting a cookie will only cause the browser to > > stop reporting that cookie to the server when you restart the browser. > > > > A good way to tell if this is what is actually happening is, if you > > are able, sniff your HTTP traffic and see if the browser is supplying > > the offending Cookie: header. But this might be more effort than you > > want to put out (I know it would be for me). > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Tom David Kirkpatrick Virus Bulletin Web Developer, Virus Bulletin Tel: +44 1235 555139 Web: www.virusbtn.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
