Introduction

So in our last post, we talked about setting up the Visual Studio 2015 C# MVC WebApp project. This application is going to be our API for communicating with Azure DocumentDb.

Now this post talks about a mistake I made and the fall out of that mistake.

 

The Mistake

So I made a big mistake, I am not sure what I was doing or thinking but I was cleaning up the Azure Active Directory applications. By mistake, I deleted the Azure Active Directory application for our API application!

Oooppss!

So what did I do to resolve this, well I created a new Azure Application which of course created a new ClientId and Password.

I then went through recreating the application as I remembered. I then updated the ClientId inside the web.config for the MVC Web API application.

 

 

401 Unauthorised Exceptions

Now unfortunately these changes did not work. For some reason I kept getting 401 Unauthorised exceptions when trying to access the API.

This was massively frustrating and I spent a few hours trying to resolve the issue.

There were various things that I looked at. I will be honest I can’t remember all the things that I tried but I did update the Client Id and Password a couple of times, in case I did it incorrectly. This was achieved by deleting and recreating the Azure AD Application.

However, the approach that started to give me some results involved using the “Server Explorer”  in Visual Studio.

 

Server Explorer to the rescue

The Server explorer is pretty cool, I used it last episode to attach and debug the Web App API. This time, I used the Server Explorer to browse the file system in the cloud.

 

I ended up looking through the file system and opened the web.config. I was  checking the settings and it was then I noticed that the Azure App Client Id was set to the deleted Azure App Client Id rather than my new one.

If I changed the Client Id in the web.config and save it via the Server Explorer then the application would start to work and the client could authenticate successfully against the API!

However, as soon as I published the application it would stop working!

 

 

 

What’s going on? Why won’t the ClientId die?

I used the find tool  (ctrl+ff) in Visual Studio and searched for the old App Id. I ended up finding it in the .pubxml  file!

Ahh, so every time I publish the application, it would reconfigure the web.config file and incorrectly setup the Azure Application’s Client Id, that makes sense!

Expanding the Project->Properties->PublishProfiles folder, I found the .pubxml file.

I updated the <ADClientAPPID> element value to the new Azure AD and then published the application into Azure.

The next thing that I had to do was update the Angular client Azure application and make sure that it had access to our newly created Azure Application for the MVC .NET application.

This was achieved by browsing on https://manage.windowsazure.com, browsing to the Active Directory section. Clicking on the Azure aplication related to the Angular Client and adding the permission to the client for the new application.

 

Conclusion

Do not delete the Azure AD application!!

if you do make sure you check your publishing settings and also update any Azure applications that use it.

 

Next Episode

In the next episode, we will start building out the API so that we can store and save Invoice objects in our API layer rather than just using the client side JavaScript.

I hope you found this post useful, to be honest I hope you don’t as that way I know you haven’t deleted your Azure Application by mistake!