Authorization and ASP.NET MVC Caching

Question

I'm confused on ASP.NET MVC caching and authorization and in dire need of some clarification.

My self-made authorization attribute inherits from AuthorizeAttribute. Its overridden AuthorizeCore method runs every time, even if I set an [OutputCache] attribute on a controller action. I understand that part.

Now the mind bender for me: AuthorizeCore will fail every time now when I actually do output caching and the page is served from the cache. The reason is that when the request is cached, the httpContext.Session supplied with AuthorizeCore is null!? Here's some simplified code:

protected override bool AuthorizeCore(HttpContextBase httpContext) {
    return (Session["userId"] != null)
}

So if httpContext.Session is null, this obviously fails every time. I need to access the session though, how else can I check if the request is authorized? This doesn't make any sense - if this is how it should be then I would never be able to use cached pages together with authentication in ASP.NET MVC. Help?

Cheke

Answer 1

There are two separate questions:

1. Does authentication work with caching in MVC?
2. Does Session work before authentication in the face of a cache (even for unauthenticated users, who still have a hopefully unique session)?

The answers, respectively, are yes and no. Authentication works fine with caching. Try it with the SQL or Domain membership providers; you'll see.

Caching, however, can run before the authentication module. (For bonus points: Why?) Authentication is called only if it specifically hooks the cache (as AuthorizeAttribute does). Because sessions are user-specific, there is no guarantee you'll have a session inside of AuthorizeCore.

More bonus points: How might this change if you specified varyByUser in your cache configuration?

Unfortunately, doing authentication right is hard, because doing any kind of security right is hard. Microsoft tries to make this easier with the membership provider API. I strongly recommend using that when implementing custom authentication. I also recommend using the built-in providers and extending them instead of rewriting them whenever possible.

One other point: The ASP.NET Session provider and the ASP.NET Membership provider are entirely separate. Different membership users can share (!) a session, and, yes, you can attack a site this way. It is never safe to put security-related info in a session. Security is hard.

Allpurpose

So you're saying if I were to use a custom membership provider based on the regular asp.net membership provider I could check for user authentication with caching? Why does that work - the membership provider needs the session as well internally no? – Cheke

It is never safe to put security-sensitive information in Session, full stop. – Allpurpose

And no, the regular membership provider has close to nothing to do with Session. Read the last two links in my answer. – Allpurpose