(extraneous info omited for brevity)
So it would appears that the .Net Framework Request Processing Pipeline fires this event - and fires it for every request.
WHEN the event fires depends on whether there are Custom Modules in the pipeline.
Taken from a response on stackoverflow, user bbmud found that:
After the initialization, when the AuthenticateRequest fires, the event handlers are called in the order they where initialized, so:The MSDN site has some info on Application_AuthenticateRequest:
- FormsAuthenticationModule.AuthenticateRequest event handler
- CustomModule.AuthenticateRequest event handler
- Global.AuthenticateRequest event handler
- Global.Application_AuthenticateRequest method
TheSo if Windows Authentication is being used, then we must assume that the code to perform this authentication has already been executed and has been successful by the time the Application_AuthenticateRequest fires. event signals that the configured authentication mechanism has authenticated the current request
Similarly, if FormsAuthentication is being used, then we must assume that the code to perform this authentication has already been executed and has been successful.
Therefore, at this stage in the request processing pipeline, we should be able to safely assume that there exists an Authentication Ticket in the request (either as a Cookie, in the RequestURL or in the QueryString array) containing the users details.
From this we can create a Principle and assign it to HttpContext.User so that the our application can safely rely on this value to retrieve the information of our authenticated user eg to conduct Authorization checks and see what resources the user can/cannot access.