sualko / cloud_piwik

Track @Nextcloud users with @matomo-org (formerly Piwik)
http://sualko.github.io/cloud_piwik/
MIT License
37 stars 18 forks source link

No tracking after upgrade to to 0.5.0 - 404 error for tracking.js #63

Closed brtptrs closed 5 years ago

brtptrs commented 6 years ago

Expected behavior

Page views in Nextcloud get registered in Matoma

Actual behavior

No Tracking takes place and a 404 error gets registered for /apps/piwik/js/tracking.js

Steps to reproduce the behavior

  1. Update app to 0.5.0
  2. Call any Nextclou page
  3. Check results in Matona
  4. No more actions get registered
  5. On the nextcloud

Environment

Logs

Javascript

nextcloud_matomo_20181030175143

Nextcloud

brtptrs commented 6 years ago

I have cleared all caches in Firefox and reinstalled the app after uninstalling. I also get the same behaviour an different machines. PC, Notebook and Android. Same error also in Chrome 70

sualko commented 6 years ago

I'm sorry that you have trouble with the latest release, but I need some more help from you. The 404 is quite unusual for Nextcloud, because normally you get a 302 if you try to access an not existing route. What happens if you try to download /apps/piwik/js/tracking.js directly? Is the 404 from your webserver or Nextcloud? Do you have any related log entry in your web server or NC log? If you don't use any rewriting the url should be something like index.php/apps/piwik/.... Do you use rewriting?

brtptrs commented 6 years ago

Calling apps/piwik/js/tracking.js directly returns a "file not found" error. We don't do any fancy stuff on the nextcloud installation. Nextcloud is installed in a subdirectory, that's the only slightly unusual point.

brtptrs commented 6 years ago

Interesting is: Viewing the source code of the "page-not-found" error page does show the js code. view-source:https://path-to-mycloud/apps/piwik/js/tracking.js

*!

/ global OC /

var _paq = _paq || []; ......

sualko commented 6 years ago

Are you sure that you don't use url rewriting? Because normally the url should look like http://localhost/nextcloud/index.php/apps/piwik/js/tracking.js. The index.php is the important part here, but anyway what I meant above was that if you request something like http://localhost/nextcloud/index.php/apps/files404/ you get an 302 and not an 404. A 404 means the Nextcloud is not involved.

My guess is that you messed up your rewrite config. Look overwrite.cli.url and htaccess.RewriteBase in your nc config and check your server config.

Btw I tested both setups: With and without url rewriting and I can't reproduce your issue. Sorry.

brtptrs commented 6 years ago

I just had a look at the code inside the "cloud_piwik-0.5.0.tar.gz" release, it seems the is no file called "tracking.js" in piwik/js. Only a file called "track.js". Is this correct? On out live server there is no "tracking.js" file after an online upgrade either.

sualko commented 6 years ago

That's right. It's using a Nextcloud route and this is also the reason why there should be an index.php in the path if you don't use rewriting.

le-yak commented 5 years ago

I experienced the exact same behaviour as @brtptrs (Nextcloud v.15.0.2 / cloud_piwik v0.5.0). I believe it has something to do with which URL are allowed by default in Nextcloud, I recall reading something like this during my investigations. Unfortunately I am unable to find the reference anymore, sorry.

Fiddling with rewrite settings didn't help. Changing the script's URL from .../js/tracking.js to .../js/script fixed the issue for me.

le-yak commented 5 years ago

After further investigations, this has nothing to do with Content Security Policy, as I came to suspect at some point. This is my .htaccess freshly generated by occ maintenance:update:htaccess:

  DirectoryIndex index.php index.html
(removed for brevity)
  RewriteCond %{REQUEST_FILENAME} !\.(css|js|svg|gif|png|html|ttf|woff2?|ico|jpg|jpeg)$
(removed for brevity)
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /

Any route ending with ".js" (or any extention that appears in the exclusion list) is ignored by the rewrite engine. Changing the route to anything else solves the problem.

Setup:


The weirdest thing of all is that I too receive the JS script in the HTTP response body (tested with curl, therefore not a browser cache thing), along with the 404 status code:

$ curl -v https://example.com/apps/piwik/js/tracking.js
< HTTP/1.1 404 Not Found
(...)
* cloud_piwik v0.5.0 - 2018-10-29
(...)

Perhaps the 404 response goes through index.php: I get an empty 404 response if I remove the DirectoryIndex directive. But I'm stopping my goose chase for now...

sualko commented 5 years ago

The weirdest thing of all is that I too receive the JS script in the HTTP response body

Therefore I don't believe this is related to the rewrite rule. On an other app, I had a similar issue and it was related to the returned filename. Currently tracking.js is delivered as script. Maybe this is the reason why you get a 404, with the body tag, but I'm unsure. The only thing I can say, is that it is working for me with the same rewrite rules. I will update the app and it would be great if you could give me some feedback. It would also be helpful if you could send me your url to klaus@jsxc.org, so I can investigate this further.

sualko commented 5 years ago

It would be awesome if you could test the latest release.

brtptrs commented 5 years ago

v0.5.1 unfortunately does not solve the problem for me. Upgrade Steps (from NC front end):

I still get a 404 on apps/piwik/js/tracking.js

sualko commented 5 years ago

Can you send me your url to klaus@jsxc.org?

brtptrs commented 5 years ago

@sualko done, and thank you for the effort.

sualko commented 5 years ago

I hope I can release a fix for this bug this weekend. Sorry for the trouble.