Skip to main content

Adding custom HTTP headers with Sys.Net.WebRequestManager

Following from my last post bemoaning the lack of transport-level client crediential authentication when running inside IIS, I've started implementing my own encrypted session-transfer between clients and the server.

I want to to use Http Headers as a primary way of broadcasting session information, and also because it's difficult for a hacker to know exactly what value to add to the http headers if it's been encrypted left, right and centre.  I might extend this to using a cookie as well; but the advantage of relying on http headers is that it means clients other than web browsers will be able to access the services; so long as they can authenticate.

The primary focus of my proof of concepts at the moment are on the AJAX side, both Asp.Net Ajax and 'vanilla' Ajax (e.g. jQuery or direct XmlHttp) - since I know that in Silverlight, for example, I'll be using a different endpoint and can probably add the same authentication data to the message itself.

The scenario is this:

  • A service issues encrypted authentication 'tokens' which a client then sends to other protected services when it makes a request.  These tokens are time limited and have to be refreshed by the client within a certain time period (possibility to make it request-limited as well)
  • A protected service is called by Asp.Net AJAX through use of the auto-generated proxy code that you the ScriptManager control gets - via the /js or /jsdebug endpoint that is added to the webscript-enabled service.

Now, the issue with this is that the proxy code that Asp.Net AJAX is generating is so 'friendly' that the underlying Web requests are abstracted away from your method calls, giving you no direct way of adding any custom headers you might want to add when you make the call.

Never fear - the Sys.Net.WebRequestManager class (part of Microsoft's Asp.Net AJAX client library) provides a hook which gives you the opportunity to examine each and every web request it sends, and even modify it's contents before it leaves the browser.  In fact, setting up the handler is so simple, I'm almost embarrassed to have it sitting at the bottom of such a long preamble...

  1: //method which captures requests and adds headers etc

  2: function InterceptOutgoingRequest(sender, args)

  3: {

  4:   var currentRequest = args.get_webRequest();

  5:   currentRequest.get_headers()["MYCUSTOMHEADER"] = "MYCUSTOMVALUE";

  6: }


  8: //adding the callback to the WebRequestManager

  9: Sys.Net.WebRequestManager.add_invokingRequest(InterceptOutgoingRequest);

The 'sender' parameter will be an instance of the Sys.Net.WebRequestManager, and the 'args' parameter will be an instance of Sys.Net.WebRequest.

Now, every single Asp.Net Ajax call made by the WebRequestManager will call your custom code.


Popular posts from this blog

Serializing to attributes in WCF with DataContractSerializer

It’s a common problem – you want to return an object from a WCF service as XML, but you either want, or need, to deliver some or all of the property values as XML Attributes instead of XML Elements; but you can’t because the DataContractSerializer doesn’t support attributes (you’re most likely to have seen this StackOverflow QA if you’ve done a web search).  Most likely you’ve then migrated all your WCF service code to using the XmlSerializer (with all the XmlElement/XmlAttribute/XmlType attributes et al) – and you’ve cursed loudly.Well, I’m here to rescue you, because it is possible – and the answer to the problem is actually inferred from the MSDN article entitled ‘Types supported by the Data Contract Serializer’.The example I’m going to give is purely for illustration purposes only.  I don’t have a lot of time, so work with me!Create a new Asp.Net WCF service application, you can use Cassini as your web server (probably easier – otherwise you might have to enable Asp.Net compatibil…

Asp.Net 2 and 4 default application pool generates CS0016 IIS7.5

Before I start – if you’ve found a bunch of other articles about this around the net, tried the fixes that are mentioned and still not getting any joy – then read on – you might find this solves your problem. Earlier today I discovered that when I run any ASP.Net 2 or 4 application through IIS7.5 using the default application pools (which use ApplicationPoolIdentity) on Windows 2008 R2 x64 I get an error message similar to this: Server Error in '/MvcApplication31' Application. Compilation ErrorDescription: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0016: Could not write to output file 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\mvcapplication31\222b4fe6\4e80a86\App_global.asax.clb4bsnc.dll' -- 'The directory name is invalid. '
Source Error:[No relevant source lines]

Adding ‘Deny’ functionality to AuthorizeAttribute in Asp.Net Web API

For the web service project I’m working on at the moment I need to be able to treat authorization differently based on the hostname of the URL that requests are made through.To state more clearly – these web services will have a ‘sandbox’ mode in addition to the real mode, and the mode a request will operate under is determined as part of the controller-selection phase early in the Web API request lifecycle.  So, say that my web services will be hosted on; the sandbox will simply be note – a discussion of how this is implemented is entirely outside the scope of this article; but I’ll just say that I’ve developed an in-house multi-tenancy layer for both MVC 4 and Web API that allows us to define ‘brands’ and, under those, you can then redefine content, controllers, and even the DI container that is used.These services are going to require caller-level authentication for most operations via SCRAM Authentication (RFC 5802), and as such m…