@anonymous-piwik-user opened this issue on August 25th 2009


@anonymous-piwik-user commented on August 25th 2009

Attachment: replace html_entity_decode with urldecode in core/Tracker/Visit.php urldecode.patch

@anonymous-piwik-user commented on August 25th 2009

Attachment: phpinfo on affected server phpinfo.txt

@anonymous-piwik-user commented on August 25th 2009

Attachment: some lines from the log_visit table. The last three lines are after applying the patch log_visit_excerpt.txt

@robocoder commented on August 26th 2009

In [1439], fix #949 - replace html_entity_decode($url) with urldecode(Piwik_Common::unsanitizeInputValue($url))

@robocoder commented on August 26th 2009

According to php.net/urldecode:

The superglobals $_GET and $_REQUEST are already decoded. Using urldecode() on an element in $_GET or $_REQUEST could have unexpected and dangerous results.

That would explain why urldecode() wasn't previously required and why this problem hasn't been reported before.

@robocoder commented on August 26th 2009

In [1441], partially revert #949 pending further investigation

@robocoder commented on August 26th 2009

Unable to reproduce with:

``` phpinfo() PHP Version => 5.2.6-3ubuntu4.2

System => Linux gemini 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 ... ```

and magic_quotes_gpc on. Other than a few additional modules/extensions (APC, xdebug, sqlite, memcache), the other difference is 32-bit vs 64-bit.

@anonymous-piwik-user commented on August 26th 2009

I've set magic_quotes_gpc to Off, but even then I need my patch. Is it expected that the referer URLs are stored urlencoded in the database? Like:

@robocoder commented on August 26th 2009

No, URLs are not stored urlencoded in my database.

As the PHP documentation states, superglobals like $_GET should already be decoded. This isn't happening in your setup for some reason. So, your patch only addresses a symptom.

Can you create a test script like:


and call the script with an encoded URL. Test it locally and remotely to see if there's a difference.

@anonymous-piwik-user commented on August 26th 2009

Result of var_dump running on my server in the same directory as Piwik:

array(1) { ["url"]=>  string(18) "http://example.com" }

I have the bad feeling that my integration is faulty. I'll report more, when I find something.

@anonymous-piwik-user commented on August 26th 2009

I found the problem. In short: My fault, Piwik was correct.

Long version: The server on which Piwik is running redirects all http requests to the https page. Since the website I'm tracking is not running under https the auto detection code of Piwik tries to establish a http connection, gets redirected and only then accesses the https protected piwik instance. It the second request the url parameters are urlencoded again, so that piwik sees false data. I don't know why this happens.

I'm now running fine without my patch, after enforcing https in the tracked website.

@robocoder commented on August 26th 2009

Thanks fo clearing that up.

This issue was closed on August 26th 2009
Powered by GitHub Issue Mirror