Sharing files on Azure with deployments from Dropbox

I regularly share files with people that I want them to grab over HTTP from a location without any auth or other hurdles. They’re not sensitive files, they’re things like exercises I might be running in workshops which I want people to download from a common location. I normally put them in Dropbox, “Share Dropbox Link” then shorten it with my custom troy.hn short URL so they can read it from the screen in a meeting room and point them there. In fact this is exactly what I did last week – just as I’d done many times before – and then this started happening:

Admittedly, I’ve hit this before too and it happens once you start pumping too much content out to the public via Dropbox. They obviously don’t want the service hosting volumes of data that are served as if it was a website and I get that. I needed something a bit more reliable though so I decided to tackle it by using Azure to publish the Dropbox content to a website which also means I can do a few other neat things too. Here’s what I’ve done:

Firstly, you get yourself a website. If you’ve already got a basic or standard web hosting plan with Azure then it’s free as you can load those guys up with as many sites as the service can bear. Once the site is there (I called mine “troyhuntfiles”), you’ll see an option to set up continuous deployment:

Now this is slightly misleading because as you’ll see soon, this process won’t really be “continuous” deployment, but this is where we’ll kick things off from. So into the deployment settings:

After choosing “Dropbox”, it’ll do some auth to make sure it has access to your content:

The Dropbox website challenges for a logon:

And now we begin doing the OAuth dance:

Once this is done, the Dropbox client lets us know there’s something new to look at:

And sure enough, I now have an “Apps” folder with an “Azure” folder within it:

This is empty bar a hidden Dropbox file:

Back in the browser, now that the OAuth magic is complete I get a folder named after the website which is then also created in the image above within that Azure directory:

Rollbacks might be useful for some purposes, but I’m not going to need them here:

And we’re done! Except that we have no deployments:

Nothing once we drill down into deployments either:

A quick hit on the “Sync” button though and magic happens:

We can drill down into the deployment details and see what happened – I’d dropped a single file into it before syncing so we’re seeing “1 change” in the message below:

And this now means we can go over to the website and see things actually working:

Except that path is a bit verbose, let’s shorten it by adding a web.config with a URL rewrite rule:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="short" stopProcessing="true">
          <match url="^short$" />
          <action type="Rewrite" url="Hey - it's a file.txt" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

I’ll also add a domain to make things look extra slick:

And that is it! Now when I want to add a file to the site I just place it in Dropbox, add a URL rewrite rule if I want a different path to the actual file name and then hit the sync button on the portal. Incidentally, apparently sync from Dropbox isn’t automatic or else you could end up with a perpetual syncing cycle if you’re editing a file and continually saving. A slicker option than going to the portal might be a quick PowerShell script to run the deploy but I tend to live with Azure open in a browser tab the whole time anyway so no biggie for me.