Page MenuHomePhabricator

Confusing error message when trying to register an account over HTTP with `security.require-https`
Open, Needs TriagePublic

Description

I've been playing around with this for a few hours and I think that it is an upstream bug. I've setup a new Phabricator host and I can't seem to create the first (admin) user account. Steps to reproduce:

  1. Setup a new Phabricator installation.
  2. Initialize the database schema.
  3. Navigate to /auth/register and complete the form.
  4. Hit submit.

I always seem to get an exception:

Unhandled Exception ("AphrontMalformedRequestException")	

You are trying to save some data to Phabricator, but the request your browser made included an incorrect token. Reload the page and try again. You may need to clear your cookies.
This was a Web request.
This request had an invalid CSRF token.

Event Timeline

I tried to reproduce this on a Phacility host, but it doesn't reproduce there because the first user account is setup via OAuth.

Actually, I figured it out... The problem was that I had security.require-https set to true but I hadn't yet setup HTTPS so I was only using plain old HTTP.

joshuaspence renamed this task from Unable to create initial user account to Confusing error message when trying to register an account over HTTP with `security.require-https`.Apr 13 2017, 6:20 AM

Was this on a test install on localhost? I can only reproduce this if the remote address is part of cluster.addresses.

In particular, when you connect over HTTP to a security.require-https install, we normally just immediately redirect you to https://....

However, we don't do this for "intracluster requests" since they might be coming from the daemons or from other application hosts.

We don't have a great way to tell if an intracluster-originated HTTP request is a local user testing things with a web browser or not. We could require all intracluster requests to have some sort of header or something to explicitly identify them as intracluster, but this feels a little heavy to me and inconvenient for making services talk to one another.

I have a change to clarify this particular error, just wanted to make sure I'm not missing something.

Was this on a test install on localhost? I can only reproduce this if the remote address is part of cluster.addresses.

Ah yeah it was. I initially suspected that the load balancer was doing something funky, so I ended up setting up an SSH tunnel and forwarding localhost:80, which is in cluster.addresses.