Allow attaching custom HttpMessageHandler to requests

2282
4
06-20-2016 09:16 AM
Espen_RøvikLarsen
New Contributor II


Hi,

Being able to hook into the HTTP pipeline is an important concept in the System.Net.Http architecture.

My need is processing outbound requests and attaching an OAuth2 token. I am hiding AGS behind a proxy which use Oauth2.

Hope you can add this feature in a future release. Thanks

0 Kudos
4 Replies
dotMorten_esri
Esri Frequent Contributor

This is on our list for the Quartz release and can hopefully deliver something that supports your use case. To ensure it's covered could you share more specifically what you want to inject, and perhaps even how you would like to do it?

0 Kudos
Espen_RøvikLarsen
New Contributor II

Great to hear.

The code would add an Authorization request header with value "Bearer <token>". Standard OAuth 2.0 stuff - nothing fancy. The proxy reads the Authorization header and validates the request before passing it on to AGS - attaching an AGS token to it.

I have actually written this part open source as middelware for ASP.NET Core.

GitHub - espenrl/erl.AspNetCore.AgsToken

0 Kudos
dotMorten_esri
Esri Frequent Contributor

So if I were to give you a global delegate method you can assign that is called on each and every request the runtime makes, and you get a reference to the HttpRequestMessage right before it goes out. you can then (synchronously) modify it, ie add a header (and for instance only it if it matches a specific URL), that would work for you? I assume you don't need async support here? (I would be reluctant to allow for async support, since we don't want to introduce too much overhead at such a low level) ?
I assume you don't need support for handling the response? (if you get an authentication error, the runtime should raise an authentication required event where you can handle that already anyway)

0 Kudos
Espen_RøvikLarsen
New Contributor II

I do not need to handle the response in my case, no.

Async support would be nice. For the most time the request would be synchronous (due to a cached token) and every hour doing an async call to the identity server (our OAuth token lasts for an hour). Making the API having a synchronous API surface would not stop me doing a blocking call anyway. :)

Are you thinking of the overhead of the compiler generated state machine?

The ultimate solution would be attaching a custom System.Net.Http.HttpMessageHandler to the ArcGISHttpClient.

Extending HttpClient with OAuth to Access Twitter | Henrik's Blog

0 Kudos