It seems that the FormsAuthenticationModule gets handled first. This module is normally earlier than any custom module in the ASP.NET pipeline, so when AuthenticateRequest is fired, FormsAuthenticationModule will get called first, do its job and then your module’s event handler will be called.
If you really want to dig deep into this, I suggest trying to debug the ASP.NET code yourself. Here is a post how to set up your VS:
http://weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx
EDIT: I was able to confirm this behavior by setting up a web project with custom module and event handlers in Global.asax. Take a look at the source code of HttpApplication.InitInternal, the order of initialization is as follows:
- initialization of integrated modules: FormsAuthenticationModule hooks up to HttpApplication.AuthenticateRequest event
- initialization of custom modules: custom module hooks up to HttpApplication.AuthenticateRequest event
- initialization of Global class (global.asax): here we hook up to the AuthenticateRequest event
- HttpApplication.InitInternal searches for methods on Global class following the specific name pattern (e.g. Application_AuthenticateRequest), matches them to event and hooks up
After the initialization, when the AuthenticateRequest fires, the event handlers are called in the order they where initialized, so:
- FormsAuthenticationModule.AuthenticateRequest event handler
- CustomModule.AuthenticateRequest event handler
- Global.AuthenticateRequest event handler
- Global.Application_AuthenticateRequest method
Unless I missed something, there is no mechanism for stopping the event handlers to fire, so no matter what the result of FormsAuthenticationModule.AuthenticateRequest, the next handlers will still be called. I hope that helps.