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.

Is there any special character in your database password?

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.

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

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!

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

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

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.

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.

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 = @parse_ini_string($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?

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

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

I've opened matomo-org/component-ini#1 and will fix it today.

Should be fixed now.

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

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"

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

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

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

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 +…

@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)

Should be good now: b7d8133

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.

@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.

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

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

can you please check the DB Name and password
i head this error when i star learning
when Cosignatory is enable to connect with DB whis error is appear with with following error code..