Morning Session 1: Advanced Web Forms Practices – Part I

A bit of a long one here heavy on technical details. There's a cd we got that has solutions rolling in all of this stuff, so let me know and I can share all that when I get back.

Morning Session 1: Advanced Web Forms Practices – Part I
Miguel Castro
Solutions Architect

Excited about this one. Billed as a session for the seasoned .NET developer interested in out-of-the-box problem solving.
Interesting – he asked for MVC junkies to raise their hands. Out of about 200 people, one hand went up.

1. Handling SSL Pages
Should not be used for all pages (performance hit, etc)
Should be able to easily mark a page for SSL use – including the ability to switch them back and forth easily and even the ability potentially to do it without a recompile. I like it.

Technique 1: Class Interception

One base class for SSL pages and another for Non-SSL
Hard coded into code-behind, secure against change. Good because it’s more secure, but bad because you have to recompile.
So create two different classes that extend System.Web.Ui.Page - PageBase and SecurePageBase. (Note: We're doing something similar in FrontEnd using a class called GCCPage. Very useful for overriding anything in Page for every single page, as well as providing convenience methods across all pages. The only thing we have not done is branch into the SSL and Non-SSL versions of the page)
SecurePageBase just extends the regular page base - with the only difference being that a member variable (RequireSSL) is set to true instead of false.
From there - simple. Just provide a simple method called in On_Init to check to see if you (1) require SSL (using member var) and (2) are not already in a secure connection, and do a Response.Redirect to the SSL version if needed!

if(!RequireSSL and !IsSecure())
{
Response.Redirect(...)
}

Also a nice approach since you can add a check for localhost and NOT do SSL. Now you don't need to config a cert locally.

Technique 2: Custom Module to check config info

Put SSL pages into config file.
Good approach because no recompile is required. But the downside is that anyone with access to web.config can do a little more damage now. Security not THAT big of a deal since web.config is not publicly accessible.

So a config section called pageRouting and configuration element collection called securePages - with elements for all url's that need to be secured. Can also have attributes in config to do things like disable for local host or blanket disable ssl entirely -- all quickly and easily.

Note: I put some xml here - which blogspot does not let me display. Do a view source to see it I guess...






So have to create a few classes to define both the ConfigurationElementCollection and ConfigurationElement...and of course a class for the ConfigurationSection for "pageRouting." I'm looking at how easy it is to decorate classes and properties with Attributes using the .NET 2.0+ tags...and wondering why I don't do it more often.

Now it's easy to read the config section using the ConfigurationManager class and see what urls need to be SSL'd, redirecting if needed.

So he's getting into tapping the Http pipeline events (as opposed to page events) to do the redirects. He is talking about NOT using Global.asax (which, by the way, we do heavily) and instead using a class that implements IHttpModule. Lets you tap into the exact same events, but it's reusable! Gonna have to remember this.

Just implement a single event (Init(HttpApplication context)) and then you can wire into any event:

i.e. context.PostAcquireRequestState += context_PostAcquireRequestState;

Then register a new HttpModule using this class in web.config and your events get fired.

My thoughts - I like the approach for its flexibility, but I don't see the lack of a recompile as a massive advantage in our environment. It's good code and I like it better than the first approach. Longer to implement, but easy to do once it's set up. And the module created is completely reusable. More I think about it, more I'm convinced I'm totally stealing his code. I HAVE to remember this about moving stuff out of global.asax. Even if we don't use the rest, this at least is good stuff.