Eli Robillard's World of Blog.

An interesting question came through today regarding an article I did about custom error pages:

Is there a way to handle errors in a global sense and not have to re-direct to an error page?  I'd like the exception information to be caught at either the page or application level and to keep the user on the same web page with an error message at the top of the page. 

Sure, though it's a bit of work. Something to consider first: In theory the reason you want to redirect to an error page is that you have an important bit of control over it -- it won't throw further exceptions. If a page throws an exception then you want to be sure it is safe to reload that same page. If the page triggers the exception over and over and eventually times out with a browser error, users might not be better off. That said...

The ASP.NET custom error page (as configured with the customErrors element in web.config) is built into the Page object's OnError event. You could create your own Page class which inherits from the base Page and override OnError to redirect back to the page orginally requested. GetLastException will still be available for display.

At the Application_Error level you could also get the full URL requested and redirect back to it rather than to an error page. My sample code shows how to display the requested URL on the error page, it shouldn't be hard to move that string into the Application_Error event of the global.asax. As I recall, it doesn't include the original QueryString (if it exists), you may want to add that.

If redirecting the user back to the same page, you could add a parameter for Page_Load to pick up on so you can take some control to ensure the exception is not triggered again. If you choose to write a class which inherits from Page, it might be a thought to add your own Page_ErrorRecovery event (and yes, this is easier to recommend than to build).

On a different tack, a simple approach I've seen (though one that redirects to an error page) is in the source code for the ASP.NET Forums 2.0. Check out the ForumsHttpModule.cs code.

The exception management strategy in ASP.NET Forums 2.0 is:
a) Define a set of application-specific exception types.
b) Build a logging mechanism.
c) Trap the custom Application Exceptions in an HttpModule, log them and redirect the user to a page that indicates somehing went wrong.

The features are similar to what I put in the article though my goal was to preserve exception details for display back to the user. What I like about this source is its simplicity; it reads well and is easy to extend. Whichever route you take, it's a free download well worth a read. If you like its pattern, you can always change its redirects to go back to the page that bit ya.

Who are the ASPInsiders? We're a group of industry influencers and early adopters who work closely with the ASP.NET and IIS development teams in Redmond. You likely recognize many of the names on the membership roster, we're all pretty active in the developer community in one way or another. Membership is tight, and to answer the most common question off the top: There isn't much, if anything you can do to move your own name along. If you're a suitable candidate then we already know about you. If or when you receive ten nominations from existing members, we will contact you. That's the process everyone but the founders went through to become members, and it's worked well to foster a high level of trust and respect among the membership.

What do we do? That depends on the product cycle. Now that Whidbey is in public beta, the time for feature requests is past and we're really kicking the wheels and helping to find (and solve) remaining issues. If you've found something, tell one of us and we'll pass the message along. In the upcoming months you will see ASPInsiders more active in the community, helping people take full advantage of the improvements to the platform.

So what's in it for you? Well, if you have suggestions, feedback, or gripes concerning ASP.NET it's hard to know whether your voice is being heard. Tell an ASPInsider, and you will be heard. If you're interested in Whidbey and would like to know more, you can ask or hire an ASPInsider, pick up one of their books, read their articles, go see one speak, invite one to speak at your user group, or invite one (or more) out for dinner. But please, go easy on the drinks, we've got a big day tomorrow.

How do you get to know us better? Check out the web site. It's just received a make-over and some content is yet to be migrated, but it's a nice start and we'd be happy to hear your feedback. You can also check out our weblogs, I have a mostly-complete list of pages and feeds in my blogroll, check it out!

Robert Hensing recently updated the blog post that started the public debate and cites Jesper Johansson as his inspiration for his own conversion to pass phrases.

It so happens that Jesper weighs in this month with the first of a 3-part series on the topic. This is recommended reading for anyone who prefers that the time they spend protecting data not be a total waste.

When did Virtual PC become an essential app? It seems like I'm in it daily for SharePoint development and working with new Whidbey bits. A service pack is available, and in addition to helping VPC work better with XPSP2 and SMS, it contains the coolest buzzword of the day, a "Virtual Disk Precompactor." Check out the readme if you're actually curious about what that is. Or, just go get the service pack.

The October 2004 Community Technical Preview (CTP) releases are now available for download. These downloads contain a more recent version of the Express Editions than the Beta, however, CTP builds do not go through the same rigourous testing that Beta builds undergo. Therefore, do not install these builds on machines you depend on.

Go Get It. . .

Last Tuesday I posted about a potential vulnerability in ASP.NET along with some code to plug the hole. Two days later, a Microsoft Installer package was released which contains the ValidatePath HttpModule. This is a more thorough, easier-to-manage, and easier-to-deploy solution for the canonicalization issue.

While the vulnerability affects IIS 5.x and IIS 6.x should (in theory) be safe by the nature of its differences, Microsoft is recommending that this HttpModule be installed on all ASP.NET installations, 5.x and 6.x alike. Unlike the global.asax fix, this HttpModule is installed and referenced in machine.config and will secure all virtual servers and applications on the server against the vulnerability.

Are you at risk? I promised more detail on that, so here's what you need to know:

Let's call the web.config file in your application root your "primary web.config." The vulnerability outlined in the original NTBugTraq report describes an attack where a web.config located in a subfolder (call it a "secondary web.config") might not be processed. Therefore, if your secondary web.config contains more stringent security than in the application root, that extra security could be bypassed with a malformed request.

As far as I understand it, the primary web.config in the application root is always processed. If you define security and subpaths there, you're in good shape. The potential vulnerability is with subfolders which use a secondary web.config.

I don't know of any Microsoft server applications whose out-of-the-box deployment can be compromised by this method (SharePoint, BizTalk, Outlook Web Access, MCMS). But forget that, just deploy the fix. If you run Reporting Services on the same box, you will require additional steps.

A lesson to take from this is that whenever possible, deploy your administration UI in a separate application with either a separate host header (e.g. http://admin.myapp.com/) or a secondary port (e.g. http://myapp.com:2112/). On IIS 6 this also allows you to assign a separate Application Pool running under a different identity than the public site, with Anonymous access turned off, and even to assign a set of acceptable incoming IP addresses for administration of your app. These are more easily set with the IIS UI than in code.

Also, calls to retrieve data from a database should do an authorization check against the identity of the current user, or the table structure should be such that you can assign rights to data so that either a Username or Group Name may be derived from the current Principle Identity and used as a parameter in the query. In other words, be sure that the current user has rights to data before returning it. Don't assume that since a user can see a page that they should be privy to the content it serves. The can here ends at authentication, the should is the part where an authorization check happens. A good security strategy actively employs both.

Finally and most obvious, don't hardcode sensitive information in your web page source, either in the .aspx or the code-behind files. While code-behind is not at risk here, hardcoded html in subfolders which meet the criteria may be at risk.

The two previous paragraphs are no longer just good design. In companies working to comply with the Sarbanes-Oxley Act, they represent an absolute minimum. If you've been resisting, it's time to step up your game. In the meantime, go install the fix and secure your sites.

Google Desktop is the new killer application. It's the best thing thing since Google.

It indexes your local content (e.g. Outlook, Office, etc.) and the pages you view, and integrates intuitively with Google's online search. I'd say seamlessly, but there is a seam in that it differentiates between the two result sets, as it should.

What does this mean to you? Let's say I wrote an architecture document for Project Twinkle but forget where I put it. I type "architecture project twinkle" into my Google Desktop's search box and it comes back with all the documents, e-mail and web pages related to the architecture of Project Twinkle. If I don't find what I want, I can run the same search on the web with a single click.

No more Windows Explorer searches, no more cutting and pasting search terms from window to window, heck, I might not even need Lookout anymore.

Go get it, now: http://desktop.google.com

I'll be participating in an MSDN DevChat today at 1:00pm EST. The topic is SPS Developer Considerations:

This session is targeted at intermediate ASP.Net developers who are interested in developing collaborative web applications under Sharepoint and/or Windows Sharepoint Services.  We’ll cover the top 10 things to know as you move from a pure IIS platform to a SPS/WSS platform.   In the end, you’ll have a good idea for the types of apps that can be built on Sharepoint and a good idea for how to do it.  This is a developer-oriented session, delivered by developers.

My role is to answer questions in the Q&A. See you there!

Update:
This DevChat was recorded, I will post the links as soon as they become available. In the meantime I've removed the (now dead) links to the webcast.

The DevChat was led by Scott Howlett and included a nice collection of tips for SharePoint development before launching into a demo on creating custom search features on a portal site. Scott led the audience through adding fields to a list, having those fields appear in Advanced Search, and then in creating a custom query page which executes a search based on a developer-defined query. This section provided some good insight into the query structure, and is well worth reviewing when the DevChat is posted.

Thanks to all who participated, it was a terrific event!