Matomo tracker redirects fail

[aqa]

Description

I’m trying to achieve: a successful javascript tracker for website visits using matomo installed by yunohost

It seems that the javascript is being blocked. I need help troubleshooting this issue. Currently matomo isn’t tracking any site visits.

I believe the reason the JS tracker is being blocked is due to a) a MIME Type mismatch (CORB), b) a redirect problem OR c) something else entirely that I have not identified.

These issues are detailed below, and logs and diagnostics that I’ve run are available upon request.

Note: Matomo is installed on my yunohost domain. The sites I’m trying to track are on different domains, so the javascript tracker is fetched as a cross-site script.

Note: There is an error shown in firefox dev console.

GET https://xxxxx.com/yunohost/sso/?r=aHR0cHM6Ly9wYWZudXR5LmNvbS9tYXRvbW8vbWF0b21vLmpz
[HTTP/2 200 OK 62ms]

The resource from “https://xxxxx.com/yunohost/sso/?r=aHR0cHM6Ly9wYWZudXR5LmNvbS9tYXRvbW8vbWF0b21vLmpz” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff). 
Learn more: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

What I’ve tried

• changed the js matomo code, adding type=text/javascript to both the async loader and the created DOM
• Updated /etc/nginx/mime.types, changing the line for application/js to text/js

Using the “network” tab of the firefox dev tools, I noted the matomo script response headers

HTTP/2 200 OK
server: nginx
date: Fri, 05 Aug 2022 17:16:28 GMT
content-type: text/html
x-sso-wat: You've just been SSOed
cache-control: no-cache
content-security-policy: upgrade-insecure-requests
content-security-policy-report-only: default-src https: data: blob: ; object-src https: data: 'unsafe-inline'; style-src https: data: 'unsafe-inline' ; script-src https: data: 'unsafe-inline' 'unsafe-eval'
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN
permissions-policy: interest-cohort=()
strict-transport-security: max-age=63072000; includeSubDomains; preload
X-Firefox-Spdy: h2

I don’t understand these response headers:

• “content-type: text/html” <— WHY?
• “x-content-type-options: nosniff” ← from the default yunohost nginx configuration

I’m also navigating the Matomo troubleshooting guide: Matomo doesn't track any visits and pages, and shows "There is no data for this report" in all reports. FAQ - Analytics Platform - Matomo

Logs and diagnostics

• I’ve run the yunohost diagnostics, available upon request
• I’ve run the matomo diagnostics, available upon request
• I’m checking the nginx logs, available upon request.

My YunoHost server

Hardware: VPS via Digital Ocean, running Debian 10.12.
YunoHost version: YunoHost 4.3.6.3 (stable)
I have access to my server : Through SSH
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : Updated some nginx configuration, described below.

---

French, Using Google Translate

J’essaie d’obtenir un tracker javascript réussi pour les visites de sites Web à l’aide de matomo.

Il semble que le javascript est bloqué. J’ai besoin d’aide pour résoudre ce problème. Actuellement, matomo ne suit aucune visite de site.

Je crois que la raison pour laquelle le tracker JS est bloqué est due à a) une incompatibilité de type MIME (CORB), b) un problème de redirection OU c) quelque chose d’autre entièrement que je n’ai pas identifié.

Ces problèmes sont détaillés ci-dessous, et les journaux et les diagnostics que j’ai exécutés sont disponibles sur demande.

Remarque : Matomo est installé sur mon domaine yunohost. Les sites que j’essaie de suivre se trouvent sur des domaines différents, de sorte que le traqueur javascript est récupéré en tant que script intersite.

Remarque : une erreur s’affiche dans la console de développement firefox.

OBTENIR https://xxxxx.com/yunohost/sso/?r=aHR0cHM6Ly9wYWZudXR5LmNvbS9tYXRvbW8vbWF0b21vLmpz
[HTTP/2 200 OK 62ms]

La ressource de "https://xxxxx.com/yunohost/sso/?r=aHR0cHM6Ly9wYWZudXR5LmNvbS9tYXRvbW8vbWF0b21vLmpz" a été bloquée en raison d'une incompatibilité de type MIME ("text/html") (X-Content-Type-Options : nosniff).
En savoir plus : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Ce que j’ai essayé

• modifié le code js matomo, en ajoutant type=text/javascript à la fois au chargeur asynchrone et au DOM créé
• Mise à jour de /etc/nginx/mime.types, en changeant la ligne pour application/js en text/js

En utilisant l’onglet “réseau” des outils de développement firefox, j’ai noté les en-têtes de réponse du script matomo

HTTP/2 200 OK
serveur : nginx
date: ven. 05 août 2022 17:16:28 GMT
type de contenu : texte/html
x-sso-wat : vous venez d'être connecté au SSO
contrôle du cache : pas de cache
content-security-policy : upgrade-insecure-requests
content-security-policy-report-only : default-src https : données : blob : ; object-src https : données : 'unsafe-inline' ; style-src https: data: 'unsafe-inline' ; script-src https: données : 'unsafe-inline' 'unsafe-eval'
x-content-type-options : nosniff
x-xss-protection : 1 ; mode=bloc
x-download-options : noopen
x-permitted-cross-domain-policies : aucun
x-frame-options : SAMEORIGIN
permissions-policy : intérêt-cohorte=()
strict-transport-security : max-age=63072000 ; inclure les sous-domaines ; précharge
X-Firefox-Spdy : h2

Je ne comprends pas ces en-têtes de réponse :

• “type de contenu : texte/html” <— POURQUOI ?
• “x-content-type-options: nosniff” ← de la configuration nginx yunohost par défaut

Je navigue également dans le guide de dépannage Matomo : Matomo doesn't track any visits and pages, and shows "There is no data for this report" in all reports. FAQ - Analytics Platform - Matomo

Journaux et diagnostics

• J’ai exécuté les diagnostics yunohost, disponibles sur demande
• J’ai exécuté les diagnostics matomo, disponibles sur demande
• Je vérifie les journaux nginx, disponibles sur demande.

Mon serveur YunoHost

Matériel : VPS via Digital Ocean, exécutant Debian 10.12.
Version YunoHost : YunoHost 4.3.6.3 (stable)
J’ai accès à mon serveur : Via SSH
Êtes-vous dans un contexte particulier ou avez-vous effectué des réglages particuliers sur votre instance YunoHost ? : Mise à jour d’une configuration nginx, décrite ci-dessous.

[aqa]

This is the matomo tracker code, which I’m adding to the of each page that I want to track.

  <!-- Matomo -->
  <script type="text/javascript">
    var _paq = window._paq = window._paq || [];
    /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
    _paq.push(['trackPageView']);
    _paq.push(['enableLinkTracking']);
    (function() {
      var u="//xxxxx.com/matomo/";
      _paq.push(['setTrackerUrl', u+'matomo.php']);
      _paq.push(['setSiteId', '2']);
      var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
      g.type='text/javascript'; g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
    })();
  </script>

[aqa]

In nginx settings on the yunohost server, I tried both content-types – application/javascript (even though this is ol’ school) and text/javascript. I also tried turning meddling with the nosniff setting in content-type-options.

With the nosniff option I see this error, relating to the generated matomo.js file.

Error: Uncaught SyntaxError: expected expression, got '<'

This feels like a red herring to me – that the file isn’t loading properly. I don’t think this is a bug with matomo. So I restored the nginx settings.

[aqa]

I identified what was causing this issue for me.

matomo.js and matomo.php resources both redirect to yunohost SSO, thus pulling up a login page, which is HTML, and that’s why the content type doesn’t match.

If I pull up the resources URLS on a private browser (i.e. no cookies), I see the yunohost login page.

This must be the same setup for everyone using matomo on yunohost, so it shouldn’t require manually updating nginx conf.

I’ve tried

• Searching for a solution in “Users Groups and Permissions” admin section.
• Using the (legacy hack) approach of adding a “skipped_uri” as described here.

Update:
I resolved this problem by moving the matomo install from a subdirectory (xxxx.com/matomo) to it’s own domain (analytics.xxxxx.com). I also updated DNS, ssl certs, and tracking code accordingly.

This redirect problem has now been resolved, and I will therefore close this thread. I no longer see any errors on the client side through the firefox dev console.