I think this is a bug:
When I log out a user, all of the flash messages get cleared.
In my case there when a user changes his email, my email extension should send a reactivation code to his email (but it's in debug mode so the email should actually be flashed), and then the user gets automatically logged out. When he is logged out however the flash is deleted and lost. Is this a bug or expected?
Thanks,
Jonah
This is expected because flash is using session for the underlying storage. When a user is logged out, all his session data is lost.
Ok I understand it is an expected behavior, but is it one we want? It does not seem to me that flashes should even be tied to logged in users, but instead only to sessions.
Well, when a user is logged out, his session is terminated (destroyed).
Maybe you can logout the user first and then set the flash message?
Yes, I am using that workaround for now.
What I am saying though, that when a user is logged out, maybe the whole session should not be destroyed, but only the data holding the persistent user info.
Maybe you should see what other people think though
I didn't use it yet, but if session data is destroyed on logout, i agree to Jonah: Why destroy all session information? Session is just a container for the current visitors data, no matter if he's logged in or not. So i would not have expected that… Maybe make it optional?
I don’t think so. Let’s say a user is using a public computer. He logs out, and another user is using the same browser. He would have all the session data the previous user has (except those in CWebUser)
That’s definitely a security hole.
Ok. I will just log the user out before sending the email, works fine. Glad some light could be shed on this though…
Qiang, i see your point and i can live with it. But it still feels not really neccessary for me.
Lets say you have a site with public and private sections. A user might view the public section and have some settings stored in the session. Then he logs in to the private area. After he logs out, the session information for the public area will also be gone.
I still think, that it would be in the responsibility of the programmer to also remove any private data from the session on logout if that's required.
It is hard to define whether the session data is public or not. For example, even in public section, a user may not want to let other users know his trace of public activities that are kept in “public” session. Anyway, you may take a look at CWebUser::logout(). It’s very simple and you can extend it by not destroying the whole session. 
Thanks, it's o.k. as it is, as we still have all freedom we want.
I see it this way: What if a user is only in the public section and never logs in? So some data will be stored in the session anyway and the programmer is always responsible to not keep sensible data in the session.
But enough discussion. Again: I can live with the way it is now. 
Thanks.
That’s good discussion. We may come back to this in future.
To add another point to this discussion: Here’s an example, where it might get problematic to destroy anything in the session. The user has different applications under the same Vhost (same session for all). Deleting everything could get problematic in this case.
Qiang, i'm still struggling with this and am not convienced that it makes sense.
If we have multiple applications under the same Vhost but in different directories a user will always get logged out from all applications under that Vhost. Something we definitely might not always want. This limits Yii's flexibility IMO. Couldn't we at least have that configurable?
Do you mean you want to log out of one application only? I think you should set session cookie path if you have multiple apps running under the same host.
Another try to find some compromise on this topic 
If the current language selection is saved in session (like proposed in a cookbook), this language information is also lost when users log in and logout again.
Can’t we at least have a $logout($destroySession=true)? If set to false, it would only delete the auth information, not all the other potential valuable session information.
Could you create a ticket for this?