Revisit origin validation

[ErisDS]

A large part of the work to get public API access to be available, involved implementing client authentication. The Ghost admin panel is a client, and is allowed to authenticate to the API via its very own client credentials.

As a layer of security, client authentication includes origin validation. This means that we check that requests to the API come from a permitted url. These are the urls defined in config.js and at the moment can be either url or urlSSL. If the origin validation fails, the client is denied access.

This means that, if at any time you try to login or access your admin panel from a URL which is not the URL set in config.js, you will see an error, and at the moment that error is not at all clear.

The problem

At the moment, the first you might know that this is affecting you, is that you'll be unable to login. The easiest way to reproduce this right now on a standard dev install, is to try loading the admin panel from http://127.0.0.1:2368 rather than http://localhost:2368 and see that you can't login:

The access denied error message makes it look like your login has failed, when in fact, it was the admin client being denied access to the API to even try to log you in. The only other things you might see are the client console error:

And server console error:

None of which gives you a clear idea of what is wrong.

The solution

There are a few things that we can do to improve the user experience here.

The first thing is to update the error message to be as clear as possible, both on the client side and in the server console. The error should clearly state that the problem is due to the URL not matching the one in config.js, something like:

E.g. 'Access Denied from url: xxx. Please use the url configured in config.js'

As this error is most likely to happen to people just setting up or developing on Ghost (using ngrok will cause this) we should also make sure we output one of our 3-colour error messages on the console. This should be the error, some context, and how to find the solution

• Access Denied from url: xxx. Please use the url configured in config.js
• You have attempted to access your Ghost admin panel from a url that does not appear in config.js
• For information on how to fix this, please visit http://support.ghost.org/some-new-docs-url

As well as improving the error message, it may also make sense to add both localhost and 127.0.0.1 as valid origins for development mode, to account for this, in the vein of having sensible defaults. If anyone has any other ideas for sensible defaults, please say :)

At some point soon, we will be adding a UI for managing clients, where you will be able to add any additional trusted domains that you want to be able to access your blog (see #4177)

• Improve the error message on the client
• Improve the error message in the server logs
• add sensible defaults like localhost and 127.0.0.1 for dev mode

[gpestana]

I could take a look at this issue.

[ErisDS]

@gpestana really appreciate the offer of help - however as this is the last remaining piece needed before a release it is already being worked on as a matter of priority :)

[gpestana]

Sure, no problems. I see that there's many other things where I could give a hand :)

[ErisDS]

Reopening this as I've found another case for which it is broken. To reproduce:

• do a default production install: grab the zip, npm install --production, npm start --production
• go to setup, fill out the form, press enter

You'll get an endless spinner, with no error message.
In the console, we get our new, nicely formatted error message, but in the UI - just a spinner and nothing else.

The aim has always been to make it possible to install and run Ghost the first time without having to touch the config file. Now, it is absolutely required and not at all clear. I'm not 100% on what to do here.

As a first fix, the UI needs to show a sensible error message on the setup screen, cc @kevinansfield.

As a second layer, I think we need to make some sort of exception in the origin validation for this use case. Perhaps one or multiples of

• a production exception/override when url is set to http://my-ghost-blog.com
• a first-run exception/override when url is set to http://my-ghost-blog.com
• make localhost / 127.0.0.1 always allowed, not just in dev mode
• an exception for whatever the working ip is of the current machine see

Additionally, we possibly need to add a clearer warning / notification so that users understand the need to configure that URL.

Long term, we should probably prioritise some form of #2240 (auto-configuring URL in config.js).

[kevinansfield]

What seems a little strange is that the setup request works but it's the post-setup authentication that fails. It seems to me that if we're going to restrict access to the configured domain that we should also carry that restriction over to the setup until #2240 is in place?

I'll look into what options there are on the client - do we want to show an alert asking the user to configure their URL or add a "step 4" to the setup flow that explains the process/reasoning in a bit more detail?

[ErisDS]

Long term (although probably more like Mid term) the url config will be moved into the setup process. If we have write access to config.js, we'll write it, if we don't, we'll show sensible info to help the user sort it out.

Short term just from the client side perspective, we need to make it so that an error message appears under the form, exactly the same as on signin.

That + fixing up serverside with overrides for now should tide us over until we can add a proper setup step for the URL.