Michael Nachbaur <[EMAIL PROTECTED]> wrote on 26/04/2005 17:19:26: > [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. Right, well I dont mind having loads of files in the directory for now, as I am just testing at the moment. I expect that once I have it working I will move to a DB_File datastore. However, that doesn't change the fact that once you invalidate a session, it then becomes impossible to create a new one properly. > > 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). You're right, that does sound like too much effort. So instead of going down that road I have developed a simple method to invalidate my own session. This consists of three stages, first I add a <session:enumerate> tag to the root element of the the logout page, then I process it to get the XSML output that it gives, then I loop through each node and manually unset the session variable. Obviously this is not ideal as It adds extra processing to the game, but at least it works! Just to confirm then. This problem I have come across is defenately a bug right? I mean, am I supposed to be using some javascript to remove the cooke from the users browser or something !? Or is there some directive I am missing? -- 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]
