First of all it's important to note that in my application if you log out your session is still valid and you don't just get redirected back to a login page, but stay on the same page.
With that said - whichever of these two ways I use to sign out in an MVC application
FormsAuthentication.SignOut()
WebSecurity.Logout()
the effect is the same and neither of the following properties changes to reflect the logout if I immediately access them :
User.Identity.Name
Thread.CurrentPrincipal.Identity
Now - If I do a Redirect, or just reload the page then obviously these properties are updated to a null user. They just don't immediately meaning that User.Identity.Name
represents a user that just logged out.
This is a problem because I want to generate text of the form You are logged in as XXX
after login/logout - and this may be in an AJAX situation where a redirect isn't possible.
I'm curious if there's any way to trigger the IPrincipal
to reset itself after a logout (or login).
I assume people normally just Redirect()
after a Logout()
call so this is never an issue, but in an AJAX situation this is not always practical.
My current solution is to abstract the Identity in my own wrapper, and so once I'm logged out I can just update that. I'm just a little concerned that this could have some obscure side effects especially if somebody accesses IPrincipal
directly adn not through the wrapper.
This is a core limitation of the ASP.NET event pipeline as it relates to forms authentication. This also makes it vulnerable to replay attacks, as described in KB article 900111. In that article, they reference one solution to use a membership provider that stores some server-side information about the logged on user.
Membership provider seems very similar to the approach you are thinking of taking, and I wonder if you should consider using one of the built-in membership providers, or writing your custom code as a membership provider. This should address some of the concern about people not understanding the approach and calling the IPrincipal directly.
Your "logout but stay on the same page" brings the issue a little more to the fore, but ultimately you're just uncovering the same fundamental replay issue that everyone has with ASP.NET (but not everyone solves it).
This related question may also be helpful.