HttpClient, Basic authentication and Bing

On Friday, I was trying to use the Bing API to test an issue we were having while using .NET 4.5, LINQ and async/await patterns. While Bing recommends you use their .NET library, I needed to keep my example as a pure core libraries example so people could try to reproduce my issue without having to download any third party library.
The Bing API offers Basic authentication or OAuth (to keep track of how much your are using of your monthly quota). So, I had to make a remote call to a web service using Basic authentication (to keep it simple). In .NET 4.5, the recommended way tot access remote resources is to use HttpClient. I spent a fair bit of time researching this online and either it is so simple or nobody ever tried, but bottom line was that nobody has a clear and simple example
There are several key elements to a successful Bing query using HttpClient.

Header info

According to the RFC 2617, basic authentication information is passed as an HTTP header. Fortunately, the HttpClient instance does expose its header information and does provide access to common headers, including Authorization. The proper syntax is: 
using (var client = new HttpClient(new HttpClientHandler(), true))
{
   client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", "<your authenciation value>");
    ...
}

Authentication value

Following the instructions from the Bing API FAQ, I grabbed my key and slapped it on as my authentication parameter. No luck, all I got was this message:
The authorization type you provided is not supported.  Only Basic and OAuth are supported
A bit more digging revealed that I had to encode the data properly. Not a problem, .NET provides an easy way to do this: 
using (var client = new HttpClient(new HttpClientHandler(), true))
{
    var encodedKey = Convert.ToBase64String(Encoding.ASCII.GetBytes("my-Bing-API-Key"));
    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", encodedKey);
    ...
}
Same error message. Using Fiddler, I confirmed that my data was being sent properly.

The Solution

Finally, after noticing a post on a related issue, I realized that the format of the encoded string is username:password. Since the Bing API migration document states to only specify the password when using a browser, all I had to do was this: 
using (var client = new HttpClient(new HttpClientHandler(), true))
{
    var bingKey = "my-bing-api-key";
    var authentication = string.Format("{0}:{1}", string.Empty, bingKey);
    var encodedKey = Convert.ToBase64String(Encoding.ASCII.GetBytes(authentication));
    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", encodedKey);
    var data = await client.GetStringAsync("https://api.datamarket.azure.com/Bing/Search/v1/Web?Query=%27otixo%27");
}
I hope this will help the next person trying to get something apparently so trivial.

Comments

Post a Comment

Popular posts from this blog

Running Karma in specific TimeZone

Recently, I had to write some tests related to date and time. In order to tests corner cases, in particular when the UTC date was different from the local date, I had to find a way to set the timezone for my tests. There are countless posts and articles out there that explain how you can set a specific time , but I couldn’t find much about how to actually set the timezone . Many articles references how you could use your browser’s profiles to set it up, etc. But all of it seemed too complicated for my taste. In the end, I came across a gitlab-foss commit by Takuya Nogushi . Simply setting the process.env.TZ variable will do the trick. module . exports = function ( config ) { config . set ( { // your karm configuration } ) ; // Fix the timezone process . env . TZ = 'America/New_York' ; } ; I have not tested with other browsers, but this works with Chrome. The possible values for TZ are available on Wikipedia .
Read more

Calling HttpClient async functions from constructors in ASP.NET 4.5

Recently, we have been using async/await a lot in our ASP.NET MVC project. It is very powerful. However, as with most power, comes great responsibility. In multithreading, this adage can be translated to "with great parallelism, don't deadlock" . As it has been documented and explained, in the current ASP.NET stack, when you await during a request, you will get a callback on the originating thread (that's the point of await/async after all). When you make an awaitable call to let's say HttpClient.GetStringAsync() , it will want to come back on that thread also. As well explained by Stephen Cleary in his StackOverflow answer ( here ), this goes south pretty much immediately if you start blocking somewhere in the call stack. This is true if you call a Task<T>.Result . No async in constructors Unfortunately, for good reasons, constructors cannot be async. Therefore, they cannot await on anything. In our case, we needed to retrieve some data from another
Read more

Semver carets and tilde in npm

If you use npm you have likely seen notation for dependencies in your package.json like ^4.2.7 or ~3.5.3 , etc. Those are respectively caret ranges and tilde ranges . They are well documented on the npm website . And while I have become quite familiar on how to use them, I had an epiphany recently that I thought I would share. This could help newbies navigate these powerful yet odd notation. The main power of those notations versus their easier-to-understand cousins x , X and * is that you can fix the lowest version . This is usually critical, because when everybody follows semantic versioning, a library is backward compatible , but your code, as the consumer, does not have to be. Actually, it is only forward compatible . Let’s say you use a library called foo . The authors of foo , at version 1.2 decide to introduce a cool new bar() method in their package. You want to take advantage of bar() in your code. If you used the x notation in your package.json , like this: &
Read more