Deploying a Node.js with Express application on Azure

By the end of the last post, there was enough of an application to deploy it, so let’s deploy it.

Prerequisites

  • An FTP client to get at the files on Azure.
  • A GitHub account (or other source control, but this walk through uses GitHub) to deploy to Azure.
  • And an Azure account – this walk through does not require anything beyond the free account.

Setting up Azure

Log in to Azure, then click the "New +" button at the bottom right and Quick Add a website

When that’s okayed a message will appear at the bottom of the page.

Once the website has been provisioned it can be modified. From the starter page or dashboard, source control deployment can be configured

Above the starter page for new websites, below the side bar on the website dashboard.

Then select the desired source control. For this example, the deployment is in GitHub

The choose the repository and branch for the deployment.

Then press the tick icon to confirm.

Once the Azure website and source control are linked, it will start deploying the site…

Once finished the message will change to indicate that it is deployed.

 

At the point the website can be viewed. However, there are issues with it – It isn’t serving some files, as can be seen here.

What went wrong?

It is rather obvious that something is wrong. Images are not being rendered, although it looks like other things are, such as the CSS.

By examining the diagnostics tools in the browser it looks like the files are simply not found. But, there is no content.

A few blog posts ago, it was noted that if Node.js didn’t know how to handle a route then it would issue a 404 Not Found, but also it would render some content so that the browser had something to display to the user.

Here is a 404 Not Found that gets as far as Node.js:

The the browser window itself is the message that Node.js renders. It is returning a 404 status code, but it has content. Also, note that there is an X-Powered-By: Express as well as the X-Powered-By: ASP.NET from the previous example. This immediately suggests that the 404 is being issued before Node.js gets a chance to deal with the request.

It is for this reason that FTP is required so that some remote administration of the site is possible.

When the site is deployed to Azure, it recognises that it is a Node.js site and will look for an entry point. Normally it looks for a file called server.js, however, it can also work out that app.js is the file it is looking for. So, normally, the entry point into the application should be server.js for installing into Azure.

Azure creates a web.config for the application which has all the settings needed to tell IIS how to deal with the website. However, it is missing some bits. It does not know how to deal with SVG files, so it won’t serve them, even although the Node.js application understands that static content resides in a certain location.

The missing part of the web.config that is needed is:

    <staticContent>
      <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
    </staticContent>

 

Accessing the files on Azure with FTP

This example uses FileZilla as the FTP Client.

First, the credentials need to be set for accessing the site via FTP. In the Website dashboard, the side bar contains a link to “Reset your deployment credentials”.

When clicked a dialog appears that allows the username and password to be set.

Once this is filled in and the tick clicked, the details for connecting via FTP will be in the side bar on the dashboard.

These details, along with the password previously created, can be used to connect via FTP.

Once connected, navigate to the location of the web.config file, which is in /site/wwwroot and transfer the file to the source code directory. The file can now be edited along with other source code and that means that when it is deployed any relevant updates can be deployed in one action, rather than requiring additional actions with FTP.

The changes to the web.config are to add the following

    <staticContent>
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
</staticContent>

to the <configuration><system.webServer> section of the file.

Finally, add the web.config file to the repository, commit the changes to source control and push it to GitHub. It only takes a few moments for Azure to pick it up and then the portal will display a new item in the deployment history.

Refreshing the site in a browser window finally reveals the missing graphics.

The project on GitHub

This was marked as a release on GitHub as part of the Xander.Flashcards project.

Getting Tortoise Git to work with GitHub repositories

In this post I’ll walk you through installing Tortoise Git in a way that allows it to interact easily with GitHub repositories.

Download msysgit

First off download msysgit, a prerequisite for running Tortoise Git. (A the time of writing this was v1.8.3).

For the installation, I mostly accepted all the default options. The only change I made was to allow the system’s PATH environment variable to be updated. This will be required for a latter step.

I also left the default “Checkout windows-style, commit unix-style endings”, which is equivalent to the git option core.autocrlf being set to true. You probably also want to set this on if you don’t have it set already. GitHub also has an article on their site about file specific options that you might want to include in a .gitattributes file in your repository.

If you have any existing repositories on your system you can now use GitBash to work with them. At the moment each command, however, will require you to type your user name and password.

Download Tortoise Git

Then download Tortoise Git (v1.8.4 at the time of writing). If you have Windows 8 you should go for the 64-bit edition. Again, I just accepted all the default installation options.

As with GitBash in the msysgit installation, once this is set up you’ll be able to work with any existing repositories, and again each operation will require a user name and password to be allowed.

Download the git-credential-winstore

GitHub has an article on how to set up password caching (skip to “password caching” for download link) if you are using tools other than GitHub for Windows. The file requires that the path variable has the git bin folder in it. This will be the case if the option above was made when installing msysgit. I also found that a machine reboot was required before installing this as it didn’t immediately find git in the path after installing msysgit.

The git-credential-winstore install very quickly. It asks one slightly confusingly worded question, “Do you want to install git-credential-winstore to prompt for passwords?”. The correct answer is “yes”. It doesn’t mean that it will always prompt you instead of at the command line or the GUI tool, it will only prompt for a password if it does not know the credentials to use, after that it uses what’s in its credential store so you don’t get asked all the time.

When git-credentials-winstore is installed it will create a [credentials] section in your .gitconfig file which should be at C:\Users\<username>\.gitconfig

Be aware, however, that GitHub does have a nasty habit of removing the [credentials] section of the .gitconfig file. To get around this, copy the credential section to the gitconfig file in the msysgit directory (If you followed the installation defaults it will probably be in C:\Program Files (x86)\Git\etc.) You’ll have to run as administrator in order to edit that gitconfig file due to its location.

If you have multiple users on your machine you may also want to move the installed location of git-credentials-winstore as it installs in your AppData directory. However, I’ve not tried this as I’m the only user on my machine.

You can now use GitBash and Tortoise Git with your GitHub repository.

Xander.PasswordValidator

I was looking for a way to validate passwords for an upcoming project because we need to do that better than we are, so I was looking for some .NET library to do that. Unfortunately, Google only turned up a ton of regular expressions which is all fine an well, but it wasn’t really what I was looking for. I really wanted to be able to check against a dictionary of potential passwords and have it reject a password because it was in the list and it also had to check against the regular rules of “must has a number”, and so on.

So, I created Xander.PasswordValidator which is available on GitHub.

The idea is that you can create a Validator object which can then be used to evaluate the suitability of potential passwords. When creating the validator you can pass in settings from code, or have it read settings from a config file. You can extend the functionality, so if there is something that you want to check that I’ve not thought about you have points where you can extend that. If the lists of forbidden passwords are not suitable then you can add your own lists, if the rules for checking against those lists are not suitable, then you can add your own ways to check.

Also, if you write web applications using ASP.NET MVC then there is a really simple attribute you can apply to a property in your model to have the validator check the value.

Over the next few days I’ll be writing more documentation for the project and showing what can be done with it in a series of blog posts. The “official” documentation will be on the project’s wiki at GitHub. An initial version of the built code will also be available in the next few days. However, you can get the code from GitHub and build it yourself if you so desire.