I'm currently debugging a bug in /base (Umbraco v4.0.3) where the User object (HttpContext.Current.User) of the current httpcontext is null in the /base httpmodule but not null when an Umbraco page is rendered on the same site. This means that the Membership Provider checking in /base obviously fails as the internal check in Umbraco is checking for HttpContext.Current.User.Identity.IsAuthenticated which then cast an exception (obviously because User is null).
I can't get around my head why that is - am I missing something obvious (yes - but what ;-))?
Thanks for the help all. Turns out that it was a combination of things that caused the stir. The most significant was of course moving the processing to the PostAuthorizeRequest event.
Still I wasted a couple of stupid hours by not realizing that I didn't append ".aspx" to the url I was using for testing. Base was still invoked but because the module wasn't run as managed, no authorization was going on in .NET (ie. Httpcontext.User was null). Appending ".aspx" did the trick and so did appending runAllManagedModulesForAllRequests="True" to the modules element in web.config (I'm running on IIS7). Of course I could have read the manual.
However a big benefit from all of this was that /base has been re-written to use the internal member methods of Umbraco instead of its own which means full support for MembershipProvider auth (however still only umbraco members). For 4.1 I'll update to support all types of membershipProviders/roles.
HttpContext.User is null in /base httpmodule
I'm currently debugging a bug in /base (Umbraco v4.0.3) where the User object (HttpContext.Current.User) of the current httpcontext is null in the /base httpmodule but not null when an Umbraco page is rendered on the same site. This means that the Membership Provider checking in /base obviously fails as the internal check in Umbraco is checking for HttpContext.Current.User.Identity.IsAuthenticated which then cast an exception (obviously because User is null).
I can't get around my head why that is - am I missing something obvious (yes - but what ;-))?
Is it an async request to /base? If so, that's your problem.
I think the fix is in this branch:
http://umbraco.codeplex.com/SourceControl/changeset/view/66135#904813
The magic lies in inheriting from the IRequiresSessionState interface also, I think. Try and do a compare of the files?
The problem is due to the request being actioned to early in the asp.net page life cycle as far as we could tell.
The issues OnBeginRequest did not have a member avaiable at that time.
We got around the issue by creating a different handler so it went through the full page life cycle before trying to request Member.
Hope that helps
Jon
Thanks for the help all. Turns out that it was a combination of things that caused the stir. The most significant was of course moving the processing to the PostAuthorizeRequest event.
Still I wasted a couple of stupid hours by not realizing that I didn't append ".aspx" to the url I was using for testing. Base was still invoked but because the module wasn't run as managed, no authorization was going on in .NET (ie. Httpcontext.User was null). Appending ".aspx" did the trick and so did appending runAllManagedModulesForAllRequests="True" to the modules element in web.config (I'm running on IIS7). Of course I could have read the manual.
However a big benefit from all of this was that /base has been re-written to use the internal member methods of Umbraco instead of its own which means full support for MembershipProvider auth (however still only umbraco members). For 4.1 I'll update to support all types of membershipProviders/roles.
Thanks all. Now 4.0.4 is close :)
Niels, has this been fixed in 4.5.2 (if its a bug at all, perhaps just configuration issue)?
I did what you suggested and it works, so thanks
is working on a reply...