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.


Anonymous said...

Yep. Interface is the way to go.

Matthew Martin said...

So how do I do any of those in fewer lines of code than what Daniel M suggested?

BigJimInDC said...

I don't get the concern with line count... but I also would avoid the "hack" as I stated in the original post, as there are simply better ways to deal with this. Namely, learn and use Dependency Injection/Inversion of Control patterns to swap out implementations, the production one dependent on the value already being there, and the dev/test one just supplying the value from elsewhere.