Hi Peter,
>> Well, I thought I did that by including "steps to reproduce" in my original post.
Never underestimate the value of an actual app & dict. Clearly you had one, so never be shy about posting it. Posts with examples _always_ get more attention than posts without. While your steps were indeed simple, even the fewest number of steps can matter. There are a bunch of options when wizarding an app, and I'm guessing you didn't test with every possible combination. It's a LOT easier for me to work with actual code, rather than hypothetical code.
>>Any chance you could elaborate a bit on what these switches do/how to use them?
They do exactly what they say on the tin. The first changes the session ID on login or logout (while preserving the contents of the session). This is good for security as it prevents something called a Session Fixation attack. Not exactly the most common problem on the web today, but obviously every little bit helps.
The second deletes a session (and hence the session values) when the user logs out. Again a security feature, it forgets the user when they logout, leaving nothing behind in session values for bad people to possibly exploit. This is one of those "just fine off, but just that little bit better on" kind of things. Especially for really sensitive data (like banks.)
The problem with the login page is that it's possible to get there and delete the session at the same time. This causes a problem for the login form itself. So some careful thought needs to be added to the login form to make it "work" - even when no session exists. In an ideal world the login page should be "requested" when the user is ready to use it, not sit there as a "dead" page. But of course many apps redirect to the login screen when the session dies etc.
cheers
Bruce