Ever since starting to play with elk I see this message in my apache error logs quite often
"host: '' is not a legal name (unexpected end of input)"
I figured it was Elk doing it so I just did a clean install of beta 2, went to the front page, logged out and hit reload. The error appeared. Now I can sit and click reload and it appears in the log randomly.
I've also seen this in the version I was tinkering on while I was logged into an account so I don't think the login state actually matters.
In my cursory search of that error, it indicates an error in the server. Assuming apache is trying to use 'host' to do a host lookup or something. Not exactly sure, but just something I figured I'd put out there. Doesn't happen on my server.
Huh. Never saw it on the same server with SMF. When I searched google for it the references I saw pointed to AJAX errors. But if it is the server so be it.
Can you point me to the places stating it's a server error please so I can see what's going on?
Ah ok. Yes I can replicate the error message on the command line with the host command. Thank you very much to both you and IchBin.
Now I need to find where in apache or php the "host" command is being called I suppose.
Do you happen to know if Elk calls that somewhere?
Yep, Elk calls it, and that's the reason of my last "question"... that was a bit cryptic, but it would sound like: "why Elk is calling host with an empty argument and not the IP of the user?"
And Would it be enough to just check is $IP is empty?".
You probably were not seeing it in SMF because you disabled the hostname look up (somewhere in the configs, not sure where lol, you can use the admin search with hostname and you should find it. ;)).
I do think I eventually disabled that setting in SMF. If you'd like to tell me where in the Elk code the call is made and I can put in some print statements to see what's happening. My local test server may indeed be configured somewhat incorrectly. It's not a public facing server.
That's actually the reason I've not reported a little bug that everytime I install elk the theme settings are wrong so it comes up with no theme and I have to go into admin and reset it. I suppose these might be related.
mmm... what is wrong in the db? The URLs or the paths?
I give a database server of localhost.
I give a forum url of https://{mydomain.xxx} on the installer and the path on my server.
After install the theme url settings are
URL to above directory:
http://127.0.0.1/...
URL to images directory:
http://127.0.0.1/...
So somehow https://{mydomain.xxx} became http://127.0.0.1 (the path on the server is set correctly.)
I've never tried installing this on a public server, but perhaps the https:// throws the installer for a loop instead of http://
Once I set the url again in the theme settings things work fine.
I'm tempted to at least add a !empty somewhere before... What do you think
@Spuds?
Seems safe enough to add that, not sure why its getting called with nothing, but safe to add. Could also do empty || 127.0.0.1 and just return or 127.0.0.1 => localhost, no need to run host for that.
mmm... then we may have to add something for IPv6 too?... looks troublesome... no?
Okay, will start with the easy ones. ;D
@scripple if you want, you can try this:
https://github.com/emanuele45/Dialogo/commit/943ca64173af1bfb4e1ea46d71a46debcb512b28
I'm sorry, I completely missed that one line!! :(
Well, if you want to try, the one in the link above is the area where the issue should be generated. ;D
Well now that you showed me where this is called it was pretty simple to see what's going on.
In Security.php you check both $user_info ip1 and ip2. Since I've never logged in from anywhere but the local machine my ip2 is blank. The code seems to expect that in this case $ip2 should be equal to $ip1 (that's what it checks for anyway) but my $ip2 is just blank. So the host: '' comes from calling host_from_ip on my blank $user_info['ip2'].
So I guess the question is do you think $ip2 should ever be blank? If so you need to change for check from
if ($ip_number == 'ip2' && $user_info['ip2'] == $user_info['ip'])
continue;
To also check if ip2 is blank. If it shouldn't be blank I guess the question is why is mine blank?
I just checked the database. The smf database I imported from has member_ip == member_ip2. The elkarte database has member_ip2 blank.
Just to make sure it's not an importer issue I just registered a new user and only set ip and not ip2 in the database.
That's another possibility, though host_from_ip is used in a couple of other places and reading the code it may be that both the two ip are empty (no idea if it is a "real" case or just an hypothetical one), so I'd delegate the check for empty IP to host_from_ip.
That's fine, but is ip2 being blank the design or a hint there is another bug? What is the point of ip2?
That's something I was trying to understand as well.
In theory it should not be empty, but apparently it is...
And I would call that a bug, yes.
And it affects SMF 2.1 as well, but not 2.0 so yes it's a bug.
It may be this:
// Some final checking.
if (preg_match('~^((([1]?\d)?\d|2[0-4]\d|25[0-5])\.){3}(([1]?\d)?\d|2[0-4]\d|25[0-5])$~', $this->_ban_ip) === 0 || !isValidIPv6($this->_ban_ip))
$this->_ban_ip = '';
In the past it was just:
// Some final checking.
if (preg_match('~^((([1]?\d)?\d|2[0-4]\d|25[0-5])\.){3}(([1]?\d)?\d|2[0-4]\d|25[0-5])$~', $this->_ban_ip) === 0)
$this->_ban_ip = '';
And it make sense that now is overwriting all the IPs because the regexp in isValidIPv6 doesn't match an IPv4 address.
So the code should be:
// Some final checking.
if (preg_match('~^((([1]?\d)?\d|2[0-4]\d|25[0-5])\.){3}(([1]?\d)?\d|2[0-4]\d|25[0-5])$~', $this->_ban_ip) === 0 && !isValidIPv6($this->_ban_ip))
$this->_ban_ip = '';
I was thinking also to change the ban_ip method to:
public function ban_ip()
{
return !empty($this->_ban_ip) ? $this->_ban_ip : $this->client_ip();
}
Does it make sense?
Applied both fixes here:
https://github.com/emanuele45/Dialogo/commit/a486e67af57461f19d98281fc803694ba2470945