You should install Phabricator using the instructions under https://secure.phabricator.com/book/phabricator/article/installation_guide/#installing-required-comp as that FreeBSD Phabricator package isn't official (as per T4200).

This exception is a bug, and it's probably been fixed since the time that package was made and now.

I have upgraded to the current master from the github repository and run
all upgrade scripts. There is no difference in behaviour.

What protocol does the repository use? For example, if the URL looks like "svn+ssh://example.com/repo", the protocol would be "svn+ssh".

https

Note that I get the same result when I create a new credential from this URL:

/passphrase/create/

I then choose "password" and then [continue] to get the same Credential has invalid type ""! error.

Can you suggest where I should look? Is this the relevant code:

$usable_credentials = mpull($usable_credentials, null, 'getPHID');

If so, is it pulling data from the db phabricator_passphrase? In my installation that db has 5 tables, all empty.

Do you get the same error creating a Passphrase on this instance?

How do I do that differently to what I described above? Is there some other place in the UI I go to?

https://secure.phabricator.com/passphrase/create gives you an error? I have not been able to reproduce the error you are describing. Does it reproduce on this install? What, specifically, are the steps to reproducing it here?

Yes, I get the error after I choose the "password" option in /passphrase/create. Same error as when doing the same thing from the diffusion application.

To rule out potential issues, I deleted all phabricator databases and started again with a current master from github. Same problem.

Am I expected to have records in the database phabricator_passphrase before I create my first passphrase? Or is this exception because somehow I'm missing this on my classpath:

https://github.com/phacility/phabricator/tree/master/src/applications/passphrase/credentialtype

Does this server (secure.phabricator.com) give you the same error?

No. That works fine.

I would generally recommend removing the packaged version of Phabricator and installing from our source directly. We have no means of quality control over third party sources and providing support as you can see, is difficult.

Woah... as explained in a previous comment I've already done that. Twice now. First I upgraded to master from github (just read up a few comments). Then I dropped all the databases and started again from scratch.

At any rate, you don't need to be afraid of the FreeBSD package. It just pulls the code from github and drops it onto disk.

If you are unable to assist, are you able to leave the ticket open for another person to at least review?

Can you provide access to an install that exhibits the problem?

Sure. I can open some firewall rules. But I'll send the URL to you privately if that's OK so every web crawler/hacker in the world doesn't have a go at it.

Sorry, I mean full access (ie, root). If this machine is at your company, it's not something we can help with. If you have a clean AWS image or something, we can poke around, but without an easy case for us to locally reproduce an issue, we have no means of fixing any issue.

OK, thanks for your help. In the last few minutes I found where the PHP errors logs go (I'm more a Ruby/Java person) and found these logs:

Jan 6 14:49:16 <user.notice> astonish php-fpm: [2015-01-06 14:49:16] EXCEPTION: (Exception) Credential has invalid type ""! at [<phabricator>/src/applications/passphrase/controller/PassphraseCredentialEditController.php:365]
Jan 6 14:49:16 <user.notice> astonish php-fpm: #0 PassphraseCredentialEditController::getCredentialType(NULL) called at [<phabricator>/src/applications/passphrase/controller/PassphraseCredentialEditController.php:34]
Jan 6 14:49:16 <user.notice> astonish php-fpm: #1 PassphraseCredentialEditController::processRequest() called at [<phabricator>/src/aphront/AphrontController.php:33]
Jan 6 14:49:16 <user.notice> astonish php-fpm: #2 AphrontController::handleRequest(AphrontRequest) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:196]
Jan 6 14:49:16 <user.notice> astonish php-fpm: #3 AphrontApplicationConfiguration::processRequest(AphrontRequest, PhutilDeferredLog, AphrontPHPHTTPSink) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:121]
Jan 6 14:49:16 <user.notice> astonish php-fpm: #4 AphrontApplicationConfiguration::runHTTPRequest(AphrontPHPHTTPSink) called at [<phabricator>/webroot/index.php:19]

However I note that the URL is /passphrase/edit/?type=password

But

$type_const = $request->getStr('type');
$type = $this->getCredentialType($type_const);

If $type_const is null, then something isn't getting the request passed through. My hunch is something to do with the apache to php-fpm integration proxy rules, so I'll dig around that for a minute.

Yeah our main vibe on this is it's an environment issue, not a Phabricator issue. Though we are always up for improving our 'you has bad environment' checks.

Yeay! Fixed it. So the end result is:

1. Lots of phabricator doesn't use GET with parameters in the URL. Looks like it is mostly POST.
2. Passphrase creation does (and some sort of redirect to switch URLs in the middle)
3. I was missing the "QSA" in my apache RewriteRule

So if you wanted to add another check it would be that you get parameters from the URL as you expect.

Thanks for a terrific looking product!

See T2226 for discussion of similar rules (detect disabled gzip, detect missing "B").

These setup checks are tricky because we have to make a request back to the server itself, and if we aren't careful that could loop. There's also complexity in making sure the request survives network address checks (in some configurations, we will reject requests to or from 127.0.0.1, for example).