Aug 242016
 

This post is one of those brief ones I put out here as a reminder to myself and as a potential help to anyone else experiencing similar grief.

Recently, out of nowhere, I started getting the error “No valid combination of account information found” when executing a parse on a connection string for an Azure Storage Account.  Specifically, the failure occurred on

CloudStorageAccount.Parse(storageSetting);

Come to find out, in the midst of a huge merge of code, someone had inadvertently changed the connection string in the Web.config file of my ASP.NET site.  The string changed from

“DefaultEndpointsProtocol=https;AccountName=**************;AccountKey=*********

to

“DefaultEndpointsProtocol=https;Accountname=**************;AccountKey=*********

With this library, case matters and “AccountName” was changed to “Accountname”, which caused the error.

So beware, Microsoft.WindowsAzure.Storage is picky when it comes to casing.

Feb 292016
 

Microsoft’s Azure Search service is an incredible way to provide your users with a very powerful data navigation tool.  With its REST API and .NET library, it is platform agnostic, meaning that you can utilize it in your web app, mobile client, or desktop app.

Check out my series of posts on the East Five site for an introduction:  http://www.eastfive.com/2016/02/24/microsoft-azure-search-a-practical-introduction/

Nov 172015
 

I recently worked with an endpoint in an MVC project that intentionally returns a 409 conflict HTTP status code when a user posts a model with an Id that already exists in the database.  Upon encountering this conflict, the server is supposed to return the 409 status, but the client also expects to receive the conflicting record in the response body.  When running this code in the debugger and hitting the endpoint on localhost via Postman, the 409 status is returned and the existing record is shown in Postman as it is passed in the body.  However, this was not the behavior encountered when hitting this endpoint on a site deployed to Azure.

I deployed the same code that I ran in debug to a WebApp in Azure.  When I did a post to this same endpoint in the Azure site, the 409 status was returned.  However, instead of seeing the conflicting record in the response body, I received this error:

The page cannot be displayed because an internal server error has occurred.

This was strange, considering the fact that I had just seen the conflicting record returned when posting to the same endpoint on a server running in debug on my machine.  After some research, I learned that Azure is suppressing the body on purpose to mask error details (e.g. stack traces) from being shown to consumers of the API.

I found a way to ensure that the body is returned from the site on Azure when a 400 or 500 series status is encountered.  It is to be used with caution because you could expose more information than you want about 500 status, such as stack trace information.  To ensure that the body is returned in these cases, add these lines to your web.config:

Jul 172015
 

The Problem

I recently created a new ASP.NET Web Application project in Visual Studio. Upon launching it for debug in the Google Chrome browser, I was greeted with an SSL Connection Error screen from Chrome. I also noticed that the url was changed from “http:” to “https:” (https://localhost:49500/).

I looked at my project settings in Visual Studio under the Web tab and found that my Project Url was set to http://localhost:49500/, which indicated to me that the project should have been launched in as http, not https.

Project Settings with Http

There was no launching as http, and the fact that my browser was demanding that the site be secured was causing me to not be able to load and debug my project.

The Cause

I didn’t want my project launched as https and couldn’t understand why this was happening.  After consulting with an associate (thanks Tim!) I discovered that this problem was caused by a custom header setting in the Web.config file of an old project that I had debugged, coupled with the HTTP Strict Transport Security cache in my Chrome browser.

I had debugged another, existing ASP.NET project in the recent past that had this customHeader line in its Web.config file:

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Strict-Transport-Security" value="max-age=16070400; includeSubDomains" />
      </customHeaders>
    </httpProtocol>
</system.webServer>

The “Strict-Transport-Security” customHeader line causes the server (in this case http://localhost) to add a line in the response header that a HSTS-capable browser (e.g. Google Chrome) reads.  The browser takes this as a sign that any further communication (within the given time) with this server should be done via HTTPS only.  Per the Chromium.org HSTS page:

When the browser sees this, it will remember, for the given number of seconds, that the current domain should only be contacted over HTTPS. In the future, if the user types http:// or omits the scheme, HTTPS is the default.

Since the project that I debugged had this header in its Web.config, I had told all HSTS-compatible browsers that I had used in debugging to always require http://localhost to default to https.  This was borne out by looking at the HSTS cache in chrome by going to this url in the Google Chrome browser:  chrome://net-internals/#hsts and querying for localhost:

hsts cache in Chrome

The query shows “localhost” as being in the list of domains in the HSTS set.

The Solution

After finding that I had cached the domain “localhost” as requiring HTTPS, the solution was as simple as deleting the domain from my cache.  In the Google Chrome browser, I navigated to chrome://net-internals/#hsts, typed “localhost” into the Delete domain text field, and hit Delete.  After doing so, I queried for “localhost” again and received a “Not found”

Localhost not found

Then, I re-launched my project from Visual Studio into Chrome and found that my ability to launch as HTTP had returned.

http load