I haven't had the time to investigate this any deeper, but the number of people reporting that Piwik is not tracking any visits is increasing and we should take a look at it.
Quote from mutor:
I am suspecting that the problem is that the tracking URL structure (query string after piwik.php) has changed slightly with the new version (0.6.3) and many hosts don't allow to have an URL as query string variable because of security reasons (injecting malicious code from external websites).
One of the posts referenced HostGator ... sure enough, I verified they have mod_security and are filtering any URL that contains "http:/" or "https:/" (and escaped variants; note: one forward slash) Reiterating/paraphrasing #564, mod_security users don't do the due diligence to inspect the rules before installing them -- some rules are absolute sh*t. The following return a 403 Forbidden om HostGator:
I think we did something earlier, strip http:// or https:// (maybe mailto: as well?) in front of the URLs, and put them back in the tracker.
This could easily be done in trunk, probably would have to wait for a next release coming in maybe 2 weeks?
We used to strip the scheme/protocol on the server-side.
If we simply strip the protocol on the client-side, we'd lose outlinks that begin with ftp:// (also blocked by HostGator), svn://, mailto:, etc.
To reassemble this on the server implies the workaround would be to separate the schema from the rest of the URL, e.g.,
Note: this should be affecting the installer (first website setup) and the sitemanager -- as it would explain http://forum.piwik.org/index.php?showtopic=11291
HostGator and users in the forum confirm whitelisting the mod_security rule as the workaround.
At the moment, the HG mod_security rule (purportedly as a security measure against "XSS accounts") affects only $_GET parameters.
maybe it is possible to white list mod_security in .htaccess?
Otherwise, is it wontfix? if we update piwik.js to not pass http:// , we also have to update the PiwikTracker client.
I proposed that we would still send the protocol (ftp or http) but as separate parameters. The parameters (containing the protocol) can be optional. If specified, the server concatenates it with the url. This allow for backward compatibility and cases where the browser has cached piwik.js.
Newer versions of mod_security (since 2008?) can no longer be disabled via .htaccess (eg "SecFilterEngine off" causes error code 500 Internal Server Error).
I'm leaning towards making this an installation systemcheck since the mod_security rules broadly impact Piwik, eg tracker, REST API functions that accept URLs, customData that might contain URLs, etc.
The installation system check will test an actual URL to see if it fails. If so, it's an error that can't be skipped.
(An alternative would be to query a remote server to get this server's IP address, then reverse whois to see if the IP range is assigned to HostGator or The Planet. One disadvantage of this approach is that it is host provider specific...not that they should be singled out, but they are the leading source for support requests.)
These workarounds are ugly, but do-able.
(In ) refs #1460 - add .setRequestMethod("POST") to piwik.js
(In ) fixes #1460 - SitesManager - add/update site uses POST
I already documented .setRequestMethod().
I just updated the FAQ http://piwik.org/faq/troubleshooting/#faq_58.
(In ) refs #1460 - add retry loop and pause for tracking test to complete
I'll update the warning message to a new FAQ answer about mod_security support
Anthon's message is fine