January 19, 2007
|
On (not) catching ASP.NET errors
|
1819 hit(s)
Had an unusual one today. (For me, anyway.) I have a little app at work that for various reasons has to impersonate an identity. For the time being, I do this with this element in the Web.config file:<identity impersonate="true" userName="user" password="password" />
This all works fine, no problem. However, recently the user underwent a password change -- IOW, the password in this entry was now wrong. This threw a big ol' ASP.NET YSOD error (click to enlarge):
This is a bad error -- you'll note that it displays highly sensitive data right there for everyone to see. (I'm not showing you the real data, of course.)
The first order of business was to set the <customErrors> section to RemoteOnly so that ASP.NET wouldn't be splashing credentials around like that. But I also thought it would be a good idea to catch this error. The password will change again, and since it's likely that no one will remember update the credentials on file, the error is almost certain to show up again. Although the error message that ASP.NET displays is now benign (if confusing and ugly), it would be nicer to have a proper error message.
This has proved quite challenging, who knew. I began with the error handling techniques that are generally recommended -- adding an Application_Error handler to the Global.asax file[1] and, for good measure, adding a default redirect to the <customErrors> section in the Web.config file.
Made no difference -- still got the error. I posted to our internal alias for some help. Rahul Soni pointed me to a post on his blog that suggested using a module to capture the request (or response) and redirect appropriately.
Alas, that didn't work either. It's a strange error ... it's clearly an ASP.NET error, so it's being thrown after IIS hands the request to aspnet_isapi.dll. But it's being thrown before the application is instantiated -- we never even get to Application_Start.
Rahul poked around and noted that the problem comes up when the thread for the application was being created; the impersonation is used to assign an identity to the thread. But of course the thread never makes it, coz the credentials are bad. He dove in a bit further and decided that it might be possible to handle the error by overriding a method in one of the way-early classes, like AppDomainFactory. (He had it more precise than that, but foolish me, I closed the IM window in which we were discussing this and lost the conversation, d'oh.)
In any event, that looked like way too much trouble for my little app. If this were a production application for a public Web site, it might be worth investigating further. Although even then, it's not perfectly clear either where in the pipeline you can catch this error, and if you do, how exactly you can handle it. If you know how, tho, by all means let us (me) know.
|
