You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 24, 2023. It is now read-only.
(Follow-up on #1534 )
Currently, Matomo and the Matomo Tag Manager setups are hard-coded to our analytics setup. This needs to accommodate skynetpro and community portals.
Design or Proposal
Because siasky.net, skynetpro, and default community portal setups all will serve the same skylink as their homepage, we need to devise a way of either:
a) only loading this code on Skynet Labs sites
b) blocking API calls from non-Skynet Labs hosts as a way to "reject" that incoming data
c) making this configurable to allow community portals to easily configure (and/or build + deploy) their own frontend to be using their own Matomo configurations
I think C is best, but obviously the most complicated.
We should also re-consider if piwik.js should be served from the Matomo server or part of the build on Skynet. If a portal is not using the Tag Manager, then serving from Skynet makes sense, because then there is no vulnerability potentially exposed by an insecurity in the host server. But the Tag Manager re-opens the site to loading off-Skynet code, so for extended compatibility, it might be best to load piwik.js from the Matomo server.
The text was updated successfully, but these errors were encountered:
Overview
(Follow-up on #1534 )
Currently, Matomo and the Matomo Tag Manager setups are hard-coded to our analytics setup. This needs to accommodate skynetpro and community portals.
Design or Proposal
Because siasky.net, skynetpro, and default community portal setups all will serve the same skylink as their homepage, we need to devise a way of either:
a) only loading this code on Skynet Labs sites
b) blocking API calls from non-Skynet Labs hosts as a way to "reject" that incoming data
c) making this configurable to allow community portals to easily configure (and/or build + deploy) their own frontend to be using their own Matomo configurations
I think C is best, but obviously the most complicated.
We should also re-consider if
piwik.js
should be served from the Matomo server or part of the build on Skynet. If a portal is not using the Tag Manager, then serving from Skynet makes sense, because then there is no vulnerability potentially exposed by an insecurity in the host server. But the Tag Manager re-opens the site to loading off-Skynet code, so for extended compatibility, it might be best to loadpiwik.js
from the Matomo server.The text was updated successfully, but these errors were encountered: