@kghbln opened this Issue on February 23rd 2015

After upgrading from 2.10.0 to 2.11.0 or 2.11.1 it is no longer possible for Piwiki to access the database. This issue was originally reported in the user forum.

Also trying to do a fresh install from scrap leads to this issue, no matter whether I choose the PDO/MYSQL or MYSQLi adapter. The preceeding environment check done by Piwiki runs smoothly.

No issues with 2.10.0 after rolling back to this version. An credentials issue can thus be ruled out.

Environment: PHP 5.4.36-0+deb7u3 (cli), mysql Ver 14.14 Distrib 5.5.41 (Debian 7.8)

@unix-ninja commented on February 23rd 2015

I am getting this same problem. If I upgrade to 2.11.0 or 2.11.1, I get the following error:

Access denied for user 'INF'@'localhost' (using password: YES)

However, there is no such user INF to begin with. I have grepped through all my configs, and I don't see this mentioned anywhere. There is a reference to an INF key somewhere in the piwik source (I haven't looked too much into that yet).

I can confirm that if I delete my piwik folder, and drop the 2.10 (or 2.9) files in, along with my config.ini.php, everything works again.

For the sheer point of testing, I tried a new install with 2.11 and that also gives the same error, so this really doesn't look to be a config issue.

I am also using Debian 7.8 and PHP 5.4.

@peterbo commented on February 23rd 2015 Contributor

Is there any special character in your database password?

@kghbln commented on February 23rd 2015

Not in my case, not even multibyte. Just capital letters, lowercase letters and numbers - in total 23. Tested a shorter password but this did not change the cause.

@unix-ninja commented on February 23rd 2015

Define "special". I do have printable non-alphanumeric characters, but nothing from ascii extended or unicode.

@mattab commented on February 23rd 2015 Owner

Moving to 2.12.0 as quite a few users seem to experience this. please comment here if you have the bug, as we haven't yet been able to reproduce it or even understand how this could happen!

@swissi-scp commented on February 24th 2015

I am getting this same problem. The leading zero in the password has been removed by Piwik = wrong password.

@kghbln commented on February 24th 2015

In my case the password does not have a leading zero but the name of the database user. So if this happens there too ...

@unix-ninja commented on February 25th 2015

Here's some more insight. I setup a test machine under Kali and could not reproduce this. I think that's because of the username being used to connect to myql. On the unaffected machine, I used the user "moo".

However, on the affected machine, I used a hex representation of timestamps as sql usernames. I think this name is somehow being parsed incorrectly, because when I dump the Config object after it loads the config.ini.php, the username value is of type float (totally wrong).

I am still digging into this, but hopefully this helps anyone else looking narrow down the scope.

@stiXits commented on February 25th 2015

I had a similar looking errormessage. The update had deleted all database configuration from global.ini.php. After restoring them from a backup piwik 2.11.1 ran smoothly.

@unix-ninja commented on February 25th 2015

So, it looks like the issue lies in the file vendor/piwik/ini/src/IniReader.php. When this parses the config file, it first makes a call to parse_ini_string

$array = <a class='mention' href='https://github.com/parse_ini_string'>@parse_ini_string</a>($ini, true)

At which point, all of the data is actually correct. But then it calls $this->decode on the array, which executes this bit of code:

if (is_numeric($value)) {
  return $value + 0;
}

This is where it's getting messed up. If I setup a new MySQL user called 52e666 for testing (even under Kali) it hits this line, PHP thinks I meant to specify a float and converts that string to a float. Obviously, for the username key this is very wrong (and for the password field this would equally be wrong). For now, the quick fix would be to comment out the call to $this->decode in readWithNativeFunction(), but that may not be desired in the long-term. Maybe we just shove the raw values for username and password back into the array after the decode is run?

Any devs want to speak up on this one?

@mattab commented on February 25th 2015 Owner

Thanks @unix-ninja for these tips, that's useful! cc @mnapoli

@mnapoli commented on February 25th 2015 Member

Yes good catch @unix-ninja that's a bug in piwik/component-ini!

I've opened https://github.com/piwik/component-ini/issues/1 and will fix it today.

@mnapoli commented on February 25th 2015 Member

Should be fixed now.

@unix-ninja commented on February 25th 2015

Just wanted to confirm that I tested your change and it works for me here. Thanks!

@begravelsesguiden commented on March 3rd 2015

We still see the error after deploying 2.11.2-b3 which includes the IniReader.php fix.

SQLSTATE[HY000] [1045] Access denied for user 'xxxx'@'xxxx' (using password: YES)

If it's any help, the passwords starts with "00"

@unix-ninja commented on March 3rd 2015

Do you have the vendor folder in your piwik path? If so, what version is piwik/ini?

@mattab commented on March 3rd 2015 Owner

@begravelsesguiden can you confirm that the username and password are correct in your config/config.ini.php ?

@mnapoli commented on March 3rd 2015 Member

Maybe the password starts by 0 but is entirely numeric so it ends up being the number (without the 0)…

For example 0123 turns into 123 because it's a numeric value. I can add a rule so that strings starting with 0 should not considered numbers?

I think it makes a little sense, given in PHP a number starting with 0 is considered an octal number:

var_dump(0123);
// shows 83
@mnapoli commented on March 3rd 2015 Member

Another solution to be sure that doesn't reproduce: only cast to int when there is no loss when it's turned back to a string afterwards…

E.g. cast to int when (string) ($value + 0) === $value

Example of the current behavior:

  • string 0123 would be casted to 123, which if used as string means we lost a character
  • string +10 would be casted to 10, which if used as string means we lost a character too
  • string -10 would be casted to number -10 which doesn't loose any information if turned to string again

0123 would be kept as a string (that's what we want) and the only downside is that +10 would be kept as a string too. But that seems a good thing IMO, who wants to write a number starting with a +

@mattab commented on March 3rd 2015 Owner

@mnapoli good find, hopefully it's the issue experienced by @begravelsesguiden

your suggestion sounds good. (and AFAIK it's no big deal if some ints are kept as strings)

@mnapoli commented on March 3rd 2015 Member
@unix-ninja commented on March 3rd 2015

Just a thought (because there are likely to be additional finds on this one), maybe a better solution would just to be change the parser altogether to drop PHP's native ini parsers? This way you should be able to tell during parsing if a field is enclosed in quotes, in which case it is definitely a string, and if it's not then you apply type-finding logic.

If you didn't want to do that, another (ugly) way to go about it would be to compare the raw field data after parse_ini_string runs, make a quick list of any fields encapsulated in quotes, then skip fields in the list from additional processing.

@mnapoli commented on March 3rd 2015 Member

@unix-ninja we already do that: see our project https://github.com/piwik/component-ini

If using quotes, then the string stays a string whatever is in there. The problem is if the value is not inside quotes:

foo = 0123

To prevent any future problem (as I said above) I changed the behavior so that values are turned into integers if and only if there is no data loss. That means that 123 is the same as int or string -> it's OK. However 0123 will be 123 which means we loose a character. In that case the string will not be turned into an int.

That should hopefully prevent any potential data loss with numeric values.

@begravelsesguiden commented on March 4th 2015

@mnapoli your new IniReader.php fix solved my problem. THANK YOU!

@kghbln commented on March 4th 2015

Just upgraded to 2.11.2 Works perfect. Thanks for working on this and to all involved!

This Issue was closed on February 25th 2015
Powered by GitHub Issue Mirror