Tag / Publishing

by Simon Doy

Dev Diary S01E07: Deleted Azure Apps, 401, Reoccurring Client Id and Publishing Settings


 

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.

SNAGHTML4ecb65e

 

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!! Smile

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! Winking smile

by Simon Doy

Unable to create a page based on a Publishing Page Layout


Introduction

This issue reared its head a few weeks ago. One of my clients has a pretty heavily customised Intranet which uses custom site definitions with feature stapling etc.

I have advised them to use separate site collections to help keep their site collections secure but with the main advantage being that they can use separate content databases for each site collection. This is to help ensure that they don’t get large 100Gb databases and issues with SQL Server locking.

Anyway, recently we started seeing an issue where the various contributors to the site (who were not site collection admins) could not create a page using the normal site settings->create page.

They had contribute rights but would get the error message:-

“The list does not exist”

 

Solution

So I started thinking about what the problem could be. The list does not exist message was being displayed before a page has been created and as soon as the user clicked Site Settings->Create a Page.

When you create a page you get a list of page layouts to choose from. So that brought me to checking that the master page gallery was there. I thought maybe someone had deleted the list or a feature had not been activated properly.

The list was there but no permissions were set, ah I thought that will be it.

I added the [Site Name] Members and [Site Name] Owners groups giving the Owners group Contributor permissions and the Members group Reader permissions.

The users could now create page successfully.

The reason that the problem was happening is that as part of the site collection creation process the content managers were being good and cleaning up the unused out of the box publishing SharePoint groups.

These groups include the following:-

  • Approvers
  • Designers
  • Hierarchy Managers
  • Quick Deploy Users
  • Restricted Readers
  • Style Resource Readers

However, this process was removing all the permissions from the master page gallery and hence any users who which were not site collection admins could not access the list.

The next step to this solution is write a Feature Receiver to clean up the SharePoint groups and clean up the permissions, this should help make things easier and ensure that users can start using the site as soon as its setup.

That will have to wait for a further blog post though.