Saturday, July 28, 2007

Potential solutions to the prior mentioned hack about KB928365 and ASP.NET Request Header modification

As "Anonymous" asked about my referenced solutions to the hack to resolve issues with MS KB928365, I figured instead of simply writing a follow-up comment, I would simply create a follow-up post. That said, I can imagine at least two primary solutions to this, each depending on your exact situation.

First off, with regards to my situation, I can create a provider pattern solution for looking up the enterprise provided AUTHID, such that if I want to fake it, my code isn't directly coupled to a value out of the header, but simply an interface that provides an AUTHID. I would then create two separate implementations of the interface. The first implementation would be the DEV simulation implementation, which would read the AUTHID out of the XML configuration file that we are currently using to inject into the request headers (for use in DEV). The second interface implementation would be one that reads the value off of the request headers (for use in PROD). You then configure which one is in use via your web.config, or via your Dependency Injection (DI) or Inversion of Control (IoC) framework (i.e., StructureMap, Windsor, Spring.NET).

Second, if you don't have that level of control of the situation, you are probably stuck with having to create a custom reverse proxy server to sit in front of your application that injects the AUTHID before making the request directly to your application.

Overall, the first solution is an order of magnitude more desirable. It is very much the "proper" object oriented approach, as it creates a loosely coupled solution that can be easily reconfigured, and more importantly, tested. And I would also highly recommend against even considering deploying the second solution in a production environment. It should only be used for simulating things for development purposes.

Friday, July 13, 2007

Blogs vs. Articles

I love this post! It's posts like this one that I swear and Jeremy Miller are my long lost brothers. Week after week, those two get down in writing what I've been thinking about for quite some time, but until recently, didn't even bother to have a blog to write in myself.

Overall, Nielsen is simply incorrect, much as O'Brien points out. Roughly 10 years ago, as a new college grad, I spent some time in the publishing world as a Technical Editor on a number of articles and two books. I did it, because I thought wow, there could be my name in print. But just doing those few jobs, not even being the author, I quickly came to realize all of the same things Larry points out in his post, so I stopped pursuing the publishing world any further.

Since then, second to a few choice books most folks are aware of, blogs have become the primary source of learning on my end. The amount of posts that I queue up daily in Google Reader as Starred Posts and then read while commuting to work, in elevators, at lunch, in waiting rooms, in conference rooms, etc on my WM5 Smartphone makes keeping up with this stuff seamless. Toting around magazines, print-outs, and/or books just isn't practical these days.

MS KB928365, ASP.NET Request.Headers.Add() Hack No Longer Works

So a project that I am currently a part of is using an ASP.NET 2.0 HttpModule to add some additional values to the incoming HTTP request's headers in the DEV environment (i.e., our local disconnected laptops) to simulate what an enterprise single-sign-on solution is performing in the production environment. It has worked like a charm. That is until I installed the new security update for the .NET Framework 2.0 release this past Wednesday, July 10, MS KB928365.

Apparently this "hack"
has been disabled with the release of this security update.

When attempting to call Headers.Add(), with or without the above hack in place, you will now receive a PlatformNotSupported exception.

All in all, this post is by no means a rant against the security update, but simply an attempt to add a quick answer to the "Google answer machine" for those searching. I am also already aware of a number of other potentially better solutions than the one currently in place for simulating those user accounts, but for now, simply uninstalling the above referenced security update gets the team back working again.