On tirsdag 26 april 2005, 10:49, [EMAIL PROTECTED] wrote: > > But nobody else has yet reproduced this behaviour, so I don't know > > if it is a bug, or just me who confuse the system by login in and > > out, deleting cookies and stuff pretty randomly... It could be > > similar... > > Suely the taglib should be able to handle random logging in/out, > setting and unsetting of variables? Which means it must be some kind > og bug no?
Yup, probably. But if it is something that occurs under only very unusual conditions, I have to give priority to other matters. > Has anyone else found this problem? Nope. I've asked around and nobody has seen it. > > > Because once > > > <session:invalidate> has been processed, all new requests for any > > > pages result in a new session files being generated (like in my > > > previous post) - again, making it impossible to work with the > > > session. > > > > Huh? It creates a whole file for each session...? > > That's right. I have been keeping a constant eye on the session > folder and basically when you first open up the browser on the > website, a session file is created (as you would expect). As you > navigate through the site, still only one session file exists. Adding > values to the session seems to work with no problems and similarly > removing values from the session causes no problems. Uh, that's really bizarre. I've never heard anything like it before... What makes this hard to decipher is that the file management itself is done by other modules. It is passed down to Apache::Session::Flex, which again passes the management down to other things depending on your configuration. BasicSession really doesn't do a lot on it's own... :-) Deeper down, I haven't reviewed the code, so I can't really say that I know what it does. But that it should create a whole new file for each session, that's something I really don't understand... > 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... > Deleting the session files, clearing the browser cache and deleting > all the browser cookies has no effect. The only thing that will stop > new session files being created is closing the browser and reopening > it. Hmmmm, OK. The default behavior of cookies, according to the spec (which I glanced at last night), if no expiry is set, is to get deleted on exit. So, perhaps the browser isn't deleting your cookies even if you're telling it to...? > This behaviour makes working with BasicSession impossible. Surely > other people are using this taglib without this problem..?! Yup, I am... :-) Nevertheless, if we clear up some concepts here (i.e. what do you mean by "file"), there is something that tells me there is a real problem here, concerning how BasicSession handles invalidation. Possibly, the browser still sends the cookie back, but since that's been invalidated and not in the server's store, BasicSession gets confused. Something like that... And that could also be related to the weirdness I see occasionally, but rather obscurely. But I'm just speculating... > What is the relationship between AxKit::Plugin::BasicSession and > AxKit::Plugin::Session?. From what I can tell, BasicSession actually > implements more features than the Session one, but perhaps the > Session one doesn't have this problem? Apache::AxKit::Plugins::Session is an older module, but there were some namespace confusion here I think, so that's been replaced by AxKit::XSP::BasicSession. But there is also a Apache::AxKit::Plugin::Session, which is rather advanced, has many neat features, but I never quite understood it sufficiently to make it go along. It was written by Jörg Walter, who hacks now and then, but unfortunately, he's not here very often. You could take it for a spin, though, it has a steep learning curve, but other than that is really cool. Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
