This blog entry is primarily for the 1200+ attendees of the
webcast on configuration and deployment in ASP.NET 2.0 that I gave last Friday (Mar. 10, 2006). There were a couple of demos during the presentation that failed and I wanted to make sure everyone was clear on why they failed and what the problems were.
Now normally in a presentation when a demo fails, I use it as a teaching opportunity and diagnose the problem as a group - in fact, failed demos are sometimes the high point of a presentation (assuming of course you succeed in diagnosing the problem :) since developers encounter problems like this every day, and it helps to watch how someone else approaches finding a solution. The webcast format, however, makes this style of instruction prohibitively difficult. It is possible for attendees to pose questions and potentially help diagnose the problem, but with more than 1200 attendees it is just too cumbersome for me to look through the queue of questions as I try and interactively debug. The fixed time constraint is also an issue, since debugging can take an unknown amount of time and the webcast is limited to 60min or so.
Because of these limitations, I normally run through all my demos for a Webcast very carefully to make sure they are all working properly. This session was no exception, the only problem was I ran through them on a different machine from the one I ended up presenting on, so there were some configuration differences that caused the problems.
Anyway, enough excuses - let me describe what went wrong. In the first demo, I forced authentication by adding an authorization element to my web.config file disallowing anonymous users:
<authorization>
<deny users="?"/>
</authorization>
I didn't change the default authentication mode, which means it was left to "Windows" authentication (also called integrated windows authentication) which requests that the browser respond to a challenge-response using the credentials of the client as he/she is logged in (potentially prompting for alternate credentials if the first set fail). Once I tried running a page in this site, I received an access denied failure even though I was logged in as a valid user on the same machine as the server. The problem, it turned out, was that I had not enabled Integrated authentication on the virtual directory in IIS, which ASP.NET relies on to actually implement its "Windows" authentication mode (it ends up requesting that IIS perform the authentication). So once I enabled it using the following setting in IIS, it worked without a hitch:
The next failed demo was when I switched to using the membership features of ASP.NET 2.0 and forms authentication by adding an authentication element to the web.config file and setting up a couple of users in the default aspnetdb.mdf database.
<authentication mode="Forms" />
This time it refused to authenticate me no matter how many times I tried typing in the username/password (even after carefully resetting the password on the chance that I had typed it in wrong as I created the users). This time, the issue was that my browser had cookies disabled, so by changing my default privacy (cookie management) from Medium to Low, it began accepting cookies again and everything works fine.
This last problem is actually a more general problem that sites face all the time - if clients don't have cookies enabled, how to you grant them an authentication token that accompanies each request they make after passing your authentication test? ASP.NET 2.0 actually introduces a nice solution to this by automatically detecting whether a client has cookies enabled, and if he/she does not, resorting to URL mangling to store the authentication token instead. Here's the configuration setting you can add to enable this feature (which would also have fixed my problem!):
<authentication mode="Forms">
<forms cookieless="AutoDetect" />
</authentication>
Anyway, that was the extent of the failed demos for that session - I hope this helps any of you that attended and were wondering what had gone wrong :) From now on, my new policy for webcast demo prep is that it be on the exact machine I plan to run the session from - no exceptions!
Posted
Mar 13 2006, 07:50 AM
by
fritz-onion