| maligree | |
| Jul 15 2015, 10:45 AM |
| F1784107: pasted_file | |
| Aug 25 2016, 1:47 PM |
| F625013: Screen Shot 2015-07-15 at 12.41.52 PM.png | |
| Jul 15 2015, 10:45 AM |
Installs which use custom code to destroy or overwrite $_SERVER['REMOTE_ADDR'] prior to execution can fail later on in an unintuitive way.
Original Description
I'm at 184623a7c. Creating a standard user account raises an AphrontQueryException with #1048: Column 'remoteAddr' cannot be null.
I'm not immediately able to reproduce this, and see no other reports. Can you give more details on how we can reproduce this issue?
Turns out I had a broken support/preamble.php script (or misconfigured nginx, depending how you look at it), which set $_SERVER['REMOTE_ADDR'] to an empty string.
I'm pretty sure I've had that setup for a while, so it seems some recent-ish changes changed the handling of this.
It's solved for me, but perhaps crashing when writing to user logs without remoteAddr is a bit harsh?
I just had this problem as well. Turns out I had a typo in preamble.php. A more descriptive error would be nice, but with this task open at least the cause is easy to find :)
Phabricator can be configured with a "preamble" script, for making certain environmental adjustments to deal with loadbalancers. This is described in Configuring a Preamble Script.
This task was reported a while ago and we've changed some of the behavior here, so it may be obsolete or different than described above. Start by figuring out what the current behavior is:
<?php unset($_SERVER['REMOTE_ADDR']);
If it fatals with a reasonable error (like "REMOTE_ADDR not defined"), I think that's good enough and we can just close this as resolved. This may be the modern behavior (see recent, vaguely related T11487).
If it sort of works but creating a new user account fails (as in the original report) I can walk you through adding a setup issue to detect this.
FWIW, in our case the bug was also triggered by logging in for the first time (for this account) using LDAP.
Alright I was finally able to reproduce it. Calling unset($_SERVER['REMOTE_ADDR']); in the preamble didn't actually end up causing it, which is a bit strange. The only way I could get this to occur was to explicitly set $_SERVER['REMOTE_ADDR'] = null; in the preamble.
A bit more info: I'm pretty sure the column it's referring to is in the user_log table, which doesn't allow nulls. When I had unset... in the preamble, it would just populate that column with empty strings (not null). The fdasfdafdsf values are when I set REMOTE_ADDR to that string:
mysql> select action,remoteAddr from user_log; +-----------------+---------------+ | action | remoteAddr | +-----------------+---------------+ | create | 172.30.60.196 | | change-password | 172.30.60.196 | | admin | 172.30.60.196 | | login-partial | 172.30.60.196 | | login-full | 172.30.60.196 | | create | 172.30.60.127 | | system-agent | 172.30.60.127 | | email-add | 172.30.60.127 | | multi-add | 172.30.60.127 | | hisec-enter | 172.30.60.127 | | email-add | 172.30.60.127 | | hisec-exit | 172.30.60.127 | | hisec-enter | 172.30.60.127 | | email-remove | 172.30.60.127 | | hisec-exit | 172.30.60.127 | | logout | | | login-fail | | | login-partial | | | hisec-fail | | | hisec-fail | | | hisec-fail | | | login-full | | | hisec-enter | | | create | | | logout | | | login-partial | | | login-full | | | logout | | | login-partial | | | login-full | | | hisec-enter | | | create | | | multi-remove | fdasfdafdsf | | hisec-exit | fdasfdafdsf | +-----------------+---------------+
First, let's sort of limit the direct damage this misconfiguration causes by changing this line in PhabricatorUserLog->initializeNewLog():
$log->remoteAddr = idx($_SERVER, 'REMOTE_ADDR', '');
I think if you replace that with:
$log->remoteAddr = (string)idx($_SERVER, 'REMOTE_ADDR', '');
...the code should survive your rest case where $_SERVER['REMOTE_ADDR'] being set to null.
Then, let's add a setup check to detect this, since we've seen a few cases of misconfigured preambles. None of the existing setup check groups are perfect, but I think you can add this to PhabricatorPHPConfigSetupCheck.
You should be able to follow the existing checks there. The test if (empty($_SERVER['REMOTE_ADDR'])) { ... } should be sufficient to detect that configuration is bad. We can raise a message in this vein -- I'm focusing on configuration/preamble since I think that's where most of the issues we've seen come from:
No REMOTE_ADDR is available, so Phabricator can not determine the origin address for requests. This will prevent Phabricator from performing important security checks. This most often means you have a mistake in your preamble script. Consult the documentation and double-check that the script is written correctly.
Once written, visiting Config → Setup Issues with a bad preamble should raise this issue, and fixing the preamble should clear it.