Yesterday I finished my four talks in two weeks tour. Well, it might not be as much as the big names do (Stephen Forte and Clemens Vasters, for example, seem to be speaking all over the world every other week. Someone need another speaker for a change? Email below 🙂 ), but it was nice anyhow.
The rerun of my “Identities and Principals” talk went pretty well. (BTW, I finally met with Peter van Ooijen. He was present during the presentation and seemed to have enjoyed the MSDN briefings). Except for two failing demos (out of about 15). Me and my big mouth told the audience that System.Threading.Thread.CurrentPrincipal and HttpContext.Current.User were exactly the same thing in an ASP.NET scenario. Well, sort of kinda.
During the demo I changed from the latter to the first. Why? Because I had been playing with the demo a bit earlier to try some stuff. I again ran into System.Web.UI.Page.User being a read only property. And during the demo I had a sudden brainfart that told me HttpContext.Current.User was read only as well (which is not true). “Must have been left there from playing with the demo code”, I decided in a split second. So I changed it. Enter demo hell. I found out the hard way that setting the Thread.CurrentPrincipal property to a newly created principal (a GenericPrincipal with roles in my case, as opposed to the default principal that ASP.NET Forms Authentication generates) inside an HttpApplication.AuthenticateRequest event handler to will not result in the same principal travelling the ASP.NET pipeline. It will only do so via HttpContext.Current.User. Go figure.
Does anyone have any ideas on why this is so?
The other demo was on using aspnet_setreg.exe and how to configure it in your web.config. I could not get it to work during the talk (nor now). I’ll update you on this later.