I've read the AuthorizeAttribute's source code, the code comment said:
// Since we're performing authorization at the action level, the authorization code runs
// after the output caching module. In the worst case this could allow an authorized user
// to cause the page to be cached, then an unauthorized user would later be served the
// cached page. We work around this by telling proxies not to cache the sensitive page,
// then we hook our custom authorization code into the caching mechanism so that we have
// the final say on whether a page should be served from the cache.
Now i want to confirm this comment. Is it true? What's the 'worst case'? And how can i perform it?
Update：
I override OnAuthorization(), not filtered OutputCacheAttribute.
And then put a [OutputCache(Duration=30000,VaryByParam="*")] on an action which need be Authorized, but it does't work as expected, while a previously Authorized user was logged in, the latter user still need authorize. Or my question will be "How can i make the OutputCacheAttribute work"?
Update2:
After searching from the Internet, I found the reason. On .NET Framework 2.0.50727.4209 Or higher newer version, if the Page's Response contains cookies, the OutputCache will not work.
Obviously, ASP.NET MVC based on the newer version .NET Framework, with ASP.NET Forms Authenticate, the authorized page will response the authenticated ticket as cookie(HttpOnly) every time, and will not be cached.
That's weird, it seems the cache problem will never happen on authorized page in ASP.NET MVC Application. And why does the AuthorizeAttribute need to deal with it? http://androidyou.blogspot.com/2012/10/aspnet-output-cache-not-working-and.html
Update3
My mistake, the normal Forms Authenticate doesn't response the authenticated ticket as cookie every time, but my custom AuthorizeAttribute does, so there's no doubt that the normal AuthrizeAttribute deal with the cache problem.
