Why are you running arc install-certificate with a manually entered URL?

This looks closer to a server configuration issue to me and is actually a pretty strange behavior (mostly because i'm not sure how the redirect after it looks like a request is served works). If I go to http://secure.phabricator.com/api/user.whoami in the browser i get the following

{
result: null,
error_code: "ERR-CONDUIT-CORE",
error_info: "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 no CSRF token."
}

as expected or maybe not? However if i run curl http://secure.phabricator.com/api/user.whoami i get

{"result":null,"error_code":"ERR-INVALID-SESSION","error_info":"Session key is not present."}

fwiw this happens on our install as well however we haven't had any users run into it.

@epriestley Because it allows the reader of this report to reproduce the underlying issue without cloning anything or clobbering their .arcrc. Here are some less contrived scenarios, which are not mutually exclusive:

• the user makes a typo (project lacking .arcconfig, or trying to use Phabricator for the first time themselves)
• the .arcconfig comes from a time before Let's Encrypt (e.g. if you're in the middle of a git bisect that takes you back some distance)
• the admin is just attempting to migrate people to more secure services and does not expect that services will fail (or at least not fail in such an opaque and confusing manner) in the face of a redirect

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

For example, if we receive several reports of similar issues which all have typos as the root cause, we might try both "http" and "https" and suggest to the user "Did you make a typo on the protocol?". If only a handful of users ever make this mistake, it might not be worth the complexity.

On the other hand, if we receive several reports of http -> https upgrades, we might look at different changes to try to anticipate or recover from those problems.

If things are coming out of git bisect, we might fall back to trying to read .arcconfig at HEAD of master if we fail with the working copy settings and notice it's an ancestor of master (or whatever). (Or just warn about this as a possible source of errors.)

My expectation is that users should normally run arc install-certificate with an explicit URL very rarely, since it should usually be read from .arcconfig. If users are doing this during first-time setup, the documentation might need to be rewritten to be more clear (but it seems like Arcanist Quick Start doesn't tell you to do this, at least).

In T11364#186934, @epriestley wrote:

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

Pretty much all of the above hypothetical situations.

I use git worktree (yes, I know that's not supported by arc at all), and have an install which began as plain HTTP (not HTTPS) only. The install was migrated to HTTPS, and a redirect put in place so as not to break old URLs. The .arcconfig for the project I was using was not committed to the repository, because we have not yet committed as a project to switch to Phabricator, and that particular worktree happened to have an old version which referenced HTTP rather than HTTPS.

I was guiding someone through attempting to use git-phab for the first time, and as that particular worktree was the one I had open in the adjacent tab, that was the source of the .arcconfig I pasted him to use.

On the other hand, if we receive several reports of http -> https upgrades, we might look at different changes to try to anticipate or recover from those problems.

I would suggest that http -> https redirects are quite common even with sites which have not transitioned through an upgrade, e.g. http://secure.phabricator.com.

My expectation is that users should normally run arc install-certificate with an explicit URL very rarely, since it should usually be read from .arcconfig. If users are doing this during first-time setup, the documentation might need to be rewritten to be more clear (but it seems like Arcanist Quick Start doesn't tell you to do this, at least).

Anyone creating a project, or trying to use Phabricator with a particular project for the first time, will be creating .arcconfig, which is an opportunity to get this wrong.

My install hit this today: we're trying to upgrade from http -> https, but don't want to break users with the old http:// address in their .arcconfig (either because they haven't pulled master recently, are working on a different branch, are bisecting to a commit prior to the .arcconfig being updated, etc).

It's easy enough to workaround though: adjust your web server to issue a 307 redirect instead of 301/302. No idea if this is good practice or not, but it does keep the POST request data when arc retries with the new URL instead of discarding it. This seems to be where the "Session key is not present" error is coming from.