Azure Resource Manager - Part 7 - Download an Azure Publishing Profile (xml) programmatically using REST

This article is part of a series. Here's a list of all available parts.

Background

Around the web there's a lot of tips on how you can manually download the publishing profile for e.g. a Web Site, API App or other resource in Azure.

From the modern Azure Portal this is very simple from the UI:

However, one of the main things I've been searching for is a way to do this fully automated from my code, scripts or other automatic processes - in order to avoid those manual steps, but also to ensure that I always get the correct and updated data (like deployment credentials).

In this post we'll take a look at how we can use the Azure Resource Manager REST API's to in a very simple request get the Publishing Profile xml for an Azure Web Site (or other resource with publishing profiles).

Use the Azure Resource Manager REST Api to download an Azure Publishing Profile

There's almost nothing to it. Simply make sure to send the correct POST request and you should be golden. See how below.

If you're looking for the basics of getting started, please check out the other posts in this article series. Start here.

The POST Request

In the Azure Resource Manager REST API, there's an endpoint called publishxml which you can do a POST request to get from any of your web sites.

Here's an example of what that looks like:

POST https://management.azure.com/subscriptions/992cd487-c108-425e-abe7-97448deadd63/resourceGroups/ZimmerGroup/providers/Microsoft.Web/sites/FacebookConnector17ec2275/publishxml?api-version=2015-08-01

For this request you do not need any payload, you simply target your website and then append /publishxml to specify that you want to get the publish profile as xml.

The XML Response

Upon performing that request, you'll get a response that contains the Publishing Profile XML, which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<publishData>
   <publishProfile 
        profileName="FacebookConnector17ec2275 - Web Deploy" 
        publishMethod="MSDeploy" 
        publishUrl="facebookconnector17ec2275.scm.azurewebsites.net:443" 
        msdeploySite="FacebookConnector17ec2275" 
        userName="$FacebookConnector17ec2275" 
        userPWD="febBcaeyzZCk2mSjyTupWvBbnyYJmePMND71627zKunpruogyNQngE4vMlRAPF" 
        destinationAppUrl="http://facebookconnector17ec2275.azurewebsites.net" 
        SQLServerDBConnectionString="" 
        mySQLDBConnectionString="" 
        hostingProviderForumLink="" 
        controlPanelLink="http://windows.azure.com" 
        webSystem="WebSites">
      <databases />
   </publishProfile>
   <publishProfile 
        profileName="FacebookConnector17ec2275 - FTP" 
        publishMethod="FTP" 
        publishUrl="ftp://waws-prod-db3-039.ftp.azurewebsites.windows.net/site/wwwroot" 
        ftpPassiveMode="True" 
        userName="FacebookConnector17ec2275\$FacebookConnector17ec2275" 
        userPWD="febBcaeyzZCk2mSjyTupWvBbnyYJmePMND71627zKunpruogyNQngE4vMlRAPF" 
        destinationAppUrl="http://facebookconnector17ec2275.azurewebsites.net" 
        SQLServerDBConnectionString="" 
        mySQLDBConnectionString="" 
        hostingProviderForumLink="" 
        controlPanelLink="http://windows.azure.com" 
        webSystem="WebSites">
      <databases />
   </publishProfile>
</publishData>

Based on the data that I just got back, I can choose to execute MSDeploy.exe, use Kudu API's or deployments or anything else that would require me to have this specific site's publishing profile.

Why not use user-level credentials instead?

One of the requirements for me is to automatically get this site's deployment credentials specifically, and ONLY this site's credentials. I don't want to use, nor do I want to incorporate code that uses my global azure deployment credentials.

Unique credentials per web site is a lot better to use for any deployment tasks where you're managing a load of different sites, in my opinion. Separation of concerns and isolation of credentials and data is a top priority for me.

An added benefit on top of this is of course that if the password changes for the user deployment credentials, your code is now unaffected - you simply request the publishing profile, and therefore the credentials, when you need them - always getting a set of fresh credentials, but without storing them in your source code or anywhere else they might pose a danger if exposed.

Enjoy.