403 forbidden error when trying to run node.js app where default node version is missing

[nicolehaugen]

When using the Azure CLI to deploy a node.js app, if you fail to set the default node version (such as by setting is using "az appservice web config update --node-version 6.9.3 --name <app_name> --resource-group myResourceGroup") - deploy succeeds, but when the dev attempts to hit the web site to run their node.js app, they get a 403 Forbidden error saying "You don't have permission to access / on this server". This error is unintuitive and there is nothing in the failure/diagnostics logs to help the dev figure out what caused this. We need to figure out how to provide a better error message somewhere to the dev to prevent them from getting stumped by this error. Or, even more ideal is if we could prevent this all together.

Here's some more info from Nick Walker on the root issue here:

The 403 Forbidden error happens because your app is running in a PHP container, which is what happens if you never set --node-version. There is no instance of Node to execute your app, and the PHP server thinks you’re trying to directory-browse, which it doesn’t allow.

On Linux, some of the web config options perform multiple functions. --node-version not only tells Kudu what version of node to use when building, it also tells App Service that you need to run a Node container. If you don’t set any of the options that tell App Service what container to run, it defaults to PHP.

For Node, the activation service actually runs a 6.9.3 container if you specify 6.9.1, but Kudu respects the exact version for build purposes. In this particular case, the solution is to execute the az appservice web config step, but use 6.9.1 instead of 6.9.3. Just tested in PROD and the Express welcome page loads.

This workflow is much clearer in the portal, where the UX is able to show that you have a choice of container, and that a default is picked for you if you don’t make a choice. I will be making a note of this scenario, though, to see if there’s a way to improve the CLI experience.

The challenge around making the “You don’t have permission error” clearer is that that’s what PHP is configured to do, and it’s not really in our purview to change that. The solution lies further back, in making sure that the user knows that they are using a PHP container in the first place.