I’m using ASP.NET Membership. If all I ever care about is whether or not I have a non-null Membership.GetUser(), is there ever a reason to use Request.IsAuthenticated?
During development, I have inadvertently created situations where Request.IsAuthenticated is true, but Membership.GetUser() is null, so I would pass the [Authorize] filter test (which is applied globally, with [AllowAnonymous] applied specifically as required), but fail later on. While this is a situation that would probably not occur in production, I’d still like to account for it.
Given this, would it be appropriate to write a custom filter, say AuthorizeMembership or some such, that checks against Membership.GetUser() rather than Request.IsAuthenticated? Any gotchas to be aware of?
If so, would it also be okay to use that filter to populate a global UserInfo object with the user properties I typically need to process a request? I don’t use Membership Profile at all, but manage my user properties independently in a separate application database.
The main different is speed.
The
Request.IsAuthenticatedis faster and use an internal cache flag, than theMembership.GetUser().To see why the one is faster than the other I place here the code.
but the
GetUser()have too many calls because actually need more information’s to give.