ASP.NET 4.0 Part 10, A Handful Of Little Things
Welcome to part 10 of my tour through ASP.NET 4.0 [http://blog.hmobius.com/post/2010/02/09/ASPNET-40-Cometh.aspx]. In this episode, we’re going to look at a few small but useful additions to the ASP.NET 4.0 webforms template engine before we head out into the wider world of the core framework – routing, caching, sessions and so on.
We’ve seen before how Microsoft has folded features from ASP.NET 3.x and other out-of-band releases into the core ASP.NET 4.0 DLLs before. Case in point, the ASP.NET Chart control released in November 2008. This was based on Dundas Chart source code version 5.5 via a Microsoft security, accessibility, and API review. It’s now built into the core which means no additional web.config to get it running and an entry in the Data tab of the standard toolbox set.
Check out more info on the charting control here [http://weblogs.asp.net/scottgu/archive/2010/02/07/built-in-charting-controls-vs-2010-and-net-4-series.aspx] .
Three New Redirect Methods The HttpResponse class has been fitted with three new redirect methods, two to work nicely with routing, which we’ll cover later in this series, and the other to play nicer with search engines. Response.RedirectToRoute and Response.RedirectToRoutePermanent are the two we’ll note in passing for now. As you might suspect, these allow us to redirect users to a page at the end of a route we’ve defined rather than the page directly. The main difference between the two is that RedirectToRoute sends a HTTP 302 Found response back to the browser while ResponseToRoutePermanent sends a HTTP 301 Moved Permanently. To a user, both methods simply redirect their browser to a new page. To a search engine spider, 302 Found implies that the page has moved temporarily, so it will index both the old and new, temporary location. 301 Moved Permanently implies that henceforth the old location is not used and it will only index the new location going forward.
The third new redirect method, Response.RedirectPermanent, also sends a 301 Move Permanently response, but redirects straight to a page rather than a route. It has two overloads like Response.Redirect.
- RedirectPermanent(string url) * RedirectPermanent(string url, bool endResponse)
The first parameter is simply the URL of the page you wish to redirect to.
The second parameter lets you specify whether or not ASP.NET should stop processing the page and move straight to processing the Application_EndRequest method in global.asax.cs if you have one.
Side note: There has always been an issue with Response.Redirect because it calls Response.End internally which can lead to ASP.NET silently throwing ThreadAbortExceptions. A good thread on this problem can be found here [http://www.c6software.com/CodeSolutions/dotnet/ThreadAbortException.aspx]. The same is likely true of Response.RedirectPermanent, so the upshot is you might want to use these lines of code to avoid the exception being thrown although there are more thorough solutions on offer.
Response.RedirectPermanent(“http://www.danmaharry.com”, false); HttpContext.Current.ApplicationInstance.CompleteRequest();
Your mileage may vary with each approach.
Inline HTML Encoded Strings Script injection is one of those attack vectors on a website which is easily missed if you’re not careful and has the potential for a great deal of grief if you do forget. A first guard against this is to HTMLEncode any user input before being stored in the database or shown on screen. Typically this all done in the code-behind, but the latter can now also be achieved inline using the new <%: message %> syntax, which will automatically HTML encode the given message string. For example,
Encoded : <%:" " %>
Take care not to HTMLEncode a string in code-behind and then also inline with this syntax. ASP.NET will simply HTMLEncode it twice - probably not what you need.
Side note: Two other items of import with respect to ASP.NET security have happened recently.
- The Anti Cross-Site Scripting library v3.1 was released back in November 2009 [http://blogs.msdn.com/sdl/archive/2009/09/23/new-and-improved-antixss-3-1-now-with-sanitization.aspx] . Just after that, the Security Tools team announced they are to incorporate it and several other web security tools into a single amalgam, currently known as the Web Protection Library [http://blogs.msdn.com/securitytools/archive/2009/10/17/web-protection-library-ctp-release-coming-soon.aspx] . The first CTP of WPL is now available on the MS Connect site [https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=734&DownloadID=23329] and there’s a video on Channel 9 [http://channel9.msdn.com/posts/Jossie/Enhanced-Web-Protection-Library/] where the contents of WPL are explained. * Wrox Press has published the rather splendid Beginning ASP.NET Security, which quite thoroughly covers how to write your websites and web services securely and safely. It’s a great little book for beginner to intermediate programmers. Author Barry Dorrans (a newly-minted [http://idunno.org/archive/2009/12/20/and-as-a-finale-to-the-year-hellip.aspx] member of the MS Security Tools team) is also publishing any errata found in the book [http://idunno.org/Tags/Errata/default.aspx] on his blog as well which is handy. You can get it from Amazon US [http://www.amazon.com/exec/obidos/ASIN/0470743654/hmobiuscom-20] and Amazon UK [http://www.amazon.co.uk/exec/obidos/ASIN/0470743654/hmobiuscom-21].
That’s all for today. In the next episode, we’ll take a look at Routing for Webforms. Happy coding!Posted on March 4, 2010 #ASP.NET #Geek Stuff