Getting 403 in Azure Local Development Environment

Note: In searching for a solution to this problem I faced, I realize that there may be several reasons you hit a 403 when you are trying to debug an Azure solution using the local development environment. So, your mileage may definitely vary. Also, note that I don't work on any of the teams developing the great technologies at play here, so there may be easier and more foolproof ways of diagnosing the issues causing this.

I was playing around with an Azure solution consisting of a Web Role serving up some REST endpoints and a Worker Role for background processing. Seemingly without reason, I would all of a sudden get a HTTP error 403 when the browser starts up and tries to navigate to the site. I also got a 404 when I ignored the 403 and tried to invoke one of the exposed endpoints by my Web Role. Several searches online didn't seem to produce anything usable.

After trying out various things for a couple of hours, I decided to go about this in a more methodical manner. Ignoring for now the 404, thinking it could be a consequence of the 403, I decided to try to understand how the 403 came about. Looking at the site in question, I did see that the web.config had an entry allowing directory browsing. So, here was the first hint: If directory browsing is allowed, why was I getting an Access Denied when debugging the solution? Also, could the root cause of the 403 also be the root cause of the 404 returned when trying to invoke the endpoint?

It turns out the answer is yes. What I had inadvertently done was to move the web.config into a different folder in my Visual Studio solution. I didn't even consider that this would also physically move the file on the file system. Obviously, if the file is moved into a different folder (which I did actually notice, but I was too deep in the mud at that point, so I discarded that) IIS will not find it when mapping the request to the file system, and the site will not be configured correctly. So, when I moved the web.config file back to the original location in Visual Studio, things started working flawlessly again.

Morale: Think about what error message is plainly visible. If you are getting an Access Denied (403), there is a good chance that your site has been misconfigured for some simple reason. I hope this post helps others who find themselves in a similar situation.