Caught another case of this:

See also T4947 for some discussion of SELinux.

Ran into this issue myself over the past few days on a fresh install of CentOS 7 connecting to a Windows Server 2008 R2 domain controller with active directory. I was able to use ldapsearch and the provided bin/auth tool to query the active directory server successfully but yet through the web interface for phabricator it kept rejecting with the error describe in the original post. After some debugging I determined it to be due to SELinux blocking the ldap connection from httpd. Turns out you can run the following command to allow for httpd to use php-ldap to connect out to the active directory server.

rel T483960

T10612: Editing a panel causes it to duplicate in dashboard may be the same root cause as this bug.

I'm also seeing this bug.

Confirmed by updating to the latest, thanks again!

Awesome, thanks for the quick fix!

I believe this is now fixed in HEAD of master. Let us know if you're still seeing issues.

Sounds good, thanks!

Let me take a shot at it locally first, I don't immediately see a real way that D16494 could have fixed this given your repro steps.

Happy to bring those changes in and test it out. Also happy to test any patches if testing JIRA related stuff is a pain.

(I'd be a little surprised if it was and it still merits a real fix even if it doesn't happen in practice anymore.)

There is a small possibility that this was "fixed" by D16494 on Sep 5.

I believe all that stuff is fixed in HEAD of master, let us know if you're still seeing issues (other than text not being searchable: it isn't currently supported). Thanks for the report!

• text does not support searching, and does not claim to support searching (e.g., is not listed on "Constraints"). The intent is to eventually expose fulltext/content search here rather than exact-match search.
• We did not validate constraint keys, so it would appear that we might support searching on invalid constraints. D16507 fixes this: we now throw an explicit exception pointing at the error.
• link does support searching, but did not handle query constraints correctly. D16508 fixes this, and it now should apply these constraints properly.

What version of PHP are you running?

I just noticed that D229 is not actually a valid Differential Id.
It is the number of the associated Diff.

Oh, this isn't expected to work. These don't currently expose a constraint. You can find an exhaustive list of constraints in the "Custom Query Constraints" table on the API page, and no constraint will be listed for these fields.

This will be fixed when Differential moves to EditEngine, covered by T11114. I'm going to merge this there.

In PhabricatorApplicationDatasource, do a PhabricatorApplication::isClassInstalledForViewer(...) test on each application and skip it if it is not installed. You can get the class name with get_class($application_object).

Turned out the fix above:

prepped.body = prepped.body + '&projectPHIDs=%5B%22' + projectPHID + '%22%5D'

does not really work. What works is this:

import requests

I think there's another one of these in DivinerAtomController->composeTasks(). The other getDocblockMetaValue() calls anywhere in the codebase are also suspicious.

Sounds good. Let me know how I can help

Alright, thanks. I'll look at this in more detail.

Nope, that doesn't work either..

Does this work?

@epriestley You (and your team) are freaking epic. I owe you a beer (or several). If you're ever near Basingstoke, UK drop me a line!

I don't think we should actually trim() the address -- if you have bad data in LDAP, you should fix it.

This should now be fixed in HEAD of master. I've also cherry-picked it to stable.

Even though I think there's a good technical argument that our behavior is reasonable, the lifetime support cost of changing the application logic to be more similar to what browsers do is almost probably lower than the lifetime support cost of documenting this explicit port behavior, since there will be 100 more people who try the same thing in the future and maybe 5 of them will read the docs if we're lucky.

Adjusting the redirect to use `phabricator.pt.local:80' also fixes the issue, though I have removed it as I don't think anyone here still tries to use an IP...

Confirmed, removing that redirect at the top of my apache config. also resolves the problem without changing the upstream.

This is probably the issue:

I had to look that up its been so long since I fiddled with the server hosting.

Prior to that change, we did not send ports in Host: headers in requests.

Spot on! reverting that change on my arcanist client resolved any issues completely.

If you revert rPHU491ebc74d816dbe2fc8bbbbc992e8a14f8c613be in libphutil, does that fix it?

I can replicate the cURL error from a configured repository, its the same trace as that of the arc which command above:

[2016-09-05 10:06:49] EXCEPTION: (HTTPFutureCURLResponseStatus) [cURL/47] (http://phabricator.pt.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS at [<phutil>/src/future/http/HTTPSFuture.php:408]
arcanist(head=stable, ref.master=9e82ef979e81, ref.stable=10e519475290), phutil(head=stable, ref.master=c8b76485ef84, ref.stable=f748cdbc8d08)
  #0 HTTPSFuture::isReady() called at [<phutil>/src/future/Future.php:37]
  #1 Future::resolve(NULL) called at [<phutil>/src/future/FutureProxy.php:34]
  #2 FutureProxy::resolve() called at [<phutil>/src/conduit/ConduitClient.php:64]
  #3 ConduitClient::callMethodSynchronous(string, array) called at [<arcanist>/src/workflow/ArcanistWorkflow.php:332]
  #4 ArcanistWorkflow::authenticateConduit() called at [<arcanist>/scripts/arcanist.php:356]

Interesting:

echo '{}' | arc --trace call-conduit --conduit-uri http://phabricator.local/ --conduit-token cli-37au4odrzomsk54zbnolivacknw3 user.whoami
 ARGV  '/home/sam/bin/phabricator-tools/arcanist/bin/../scripts/arcanist.php' '--trace' 'call-conduit' '--conduit-uri' 'http://phabricator.local/' '--conduit-token' 'cli-37au4odrzomsk54zbnolivacknw3' 'user.whoami'
 LOAD  Loaded "phutil" from "/home/sam/bin/phabricator-tools/libphutil/src".
 LOAD  Loaded "arcanist" from "/home/sam/bin/phabricator-tools/arcanist/src".
Config: Reading user configuration file "/home/sam/.arcrc"...
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/home/sam/Coding/UMC/Src/.arcconfig".
Working Copy: Path "/home/sam/Coding/UMC/Src" is part of `git` working copy "/home/sam/Coding/UMC/Src".
Working Copy: Project root is at "/home/sam/Coding/UMC/Src".
Config: Did not find local configuration at "/home/sam/Coding/UMC/Src/.git/arc/config".
>>> [0] <conduit> user.whoami() <bytes = 117>
>>> [1] <http> http://phabricator.local/api/user.whoami
<<< [1] <http> 195,683 us
<<< [0] <conduit> 195,955 us

What do you get if you run the same command with --trace flag ?

Further testing, the standard curl request seems to be fine:

curl http://phabricator.local/api/user.whoami \
>     -d api.token=cli-37au4odrzomsk54zbnolivacknw3
{"result":{"phid":"PHID-USER-omtmnetw55dqsgt576g7","userName":"Sam","realName":"Sam","image":"http:\/\/phabricator.local\/file\/data\/g57z5iku5s2x4rpi7k6r\/PHID-FILE-xhdrpuvh5lbu7tmkfso5\/profile","uri":"http:\/\/phabricator.local\/p\/Sam\/","roles":["admin","verified","approved","activated"],"primaryEmail":"Sam@blahblah.com"},"error_code":null,"error_info":null}

It also works from the web-conduit application in phabricator http://phabricator.local/api/user.whoami, but it fails from arc:

echo '{}' | arc call-conduit --conduit-uri http://phabricator.local/ --conduit-token cli-37au4odrzomsk54zbnolivacknw3 user.whoami
Exception
[cURL/47] (http://phabricator.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS
(Run with `--trace` for a full exception trace.)

Weird.

Maybe it is ok for the import from LDAP module to trim leading and ending spaces.

To correct my previous post.
The real cause of the error is Email addresses should be in the form 'user@domain.com'.

New Info.

Hmm, yeah I wonder if it's anything we can detect on our end. Doesn't sound very common though.

I just tried again. It seems that I miss the latter part of the error message.

Do these fail for you during single person invites as well or only during LDAP?

These are valid email addresses in Phabricator. I don't have any other ideas why you're running to an error.

For example, I want to import
readonly_user readonly_user@company.com readonly_user readonly_user

I am not able to reproduce any issue with these email address formats. Do you have any suggestions for how I can do things differently?

What is the exact error message you received?

I can make it a feature request. I marked it as a bug because git diff will return something that's pretty small in this scenario.

Can you walk me through how this is a bug?

For people who suffer from this: Note that D16483 might have actually made things a little worse, by searching the DB for old messages (Not loading them though); I tested with 1M messages on an SSD drive, and I didn't see any changes, but YMMV.

I believe this should be fixed in HEAD of master. It should promote to stable in about 24 hours.