I have a server with matomo to keep the statistics of 11 OJS sites on the same server, it can track the pages that I know if they visit but I have no idea which OJS registered user makes those visits, I also have problems with spamers that are created accounts and then they use bots to try to flood the server with garbage files, having the files folder outside the root directory prevents me from hacking but not from filling my files folder with garbage, from the Apache2 access logs I have managed to determine that they do it with python and put rules in .htaccess to prevent them from doing it automatically but it’s a matter of time before they find another tool, I’m commenting on all this because one of the ways I’ve managed to detect the attack has been with matomo but I’m blind after a while to know which user or account of the OJS platform was the one who did it.
Describe the solution you’d like
From that derives my request to add a User Id variable to the matomo tracking script
The solution that I propose is to use a script code similar to that of Nextcloud that is added in the configuration form of matomo if you want to add the trace of the user and put the javascript code of matomo something like this:
if (OC && OC.currentUser && options.trackUser) {
// set user id
_paq.push(['setUserId', OC.currentUser]);
}
Where they get the UserId of the authenticated user in Nextcloud and pass it trace code
Who is asking for this feature?
I am a network administrator and I manage the hosting, among other things, of the 11 OJS sites at my university.
Excuse the language because I speak Latin-American and almost everything is self-translated by the google translator
Creating an specific plugin for matomo, piwik, analytics… means developers need to dedicate time to create and maintain those plugins (because of the tracking services, but also because of OJS evolution).
At same time, any plugin will perfectly fit with everybody’s need (you need userId, others Tags, others anonymization…).
CustomHeader let you add the JS tracker to every header’s page so looks like a perfect solution that could make everybody happy.
So, my suggestion instead of improve piwik plugin would be replace all tracking plugins by documentation explaining how to configure your favorite tracker (and probably also a comparative explaining the benefits and the downsides or each one of them.
Hello Marc, thank you very much for answering, the question is that if I use that customHeaders plugin for another statistical analysis tool that the Ministry of Higher Education of my country has, but the question is that in the end they always have to update matomo with the new OJS versions the custom script you make is not going to go with those changes unless you do it manually and that’s 11 journals and a single admin (me).
I think the suggestion to add this trace variable would be very useful and could even be incorporated into your post on detecting SPAM ( https://forum.pkp.sfu.ca/t/collaborative-list-of-spam-user-patterns /65190/9 ) which has been very useful to me, I would be willing to help as a contributor to add this feature to the matomo plugin.
I understand you more than you think. Here we have 50 magazines in 50 ojs… so every change in the configuration means 50 changes.
That’s why I’ve been exploring solutions for a long time to be able to make these changes in an automated way. Unfortunately the CLI tool is not yet powerful enough and the API doesn’t allow to modify the configuration… so for the moment I’m making changes by hand.
The solution I opted for at the time for plausible was to add the tracking to the theme (shared among the 50 journals) but I found that some pages (e.g. PDF) didn’t include the plausible script… so I ended up with the customHeaders.
But with matomo you have a solution that I find much more interesting and it consists in reading the accesses from the logs of your web server.
IMO, log analyzers are better for accuracy, but also for GDPR compliance.
Although this was a very easy functionality to activate in piwik in matomo it has been somewhat hidden and it could seem that it is only available in the paid service… but no, the code is available in gitHub and everything works perfectly.
The procedure is as simple as downloading the python3 script:
BTW, I got sidetracked by the conversation and forgot to ask you to “normalise” your FR by following the template.
We are trying to make all first “Feature Request” posts follow the same structure. We hope this will make it easier to understand the requests and, at the same time, ensure that no relevant information is missing.
So, could you please edit your post following this template?
Describe the problem you would like to solve
Example: Our editors need a way to […]
Describe the solution you’d like
Tell us how you would like this problem to be solved.
Who is asking for this feature?
Tell us what kind of users are requesting this feature. Example: Journal Editors, Journal Administrators, Technical Support, Authors, Reviewers, etc.
Additional information
Add any other information or screenshots about the feature request here.
Very interesting, what you tell me about the working module with the access.log in Matomo, I already downloaded it and I’m going to try it with more time, but in reality, the visit statistics as such up to now give me the information I need less users of the OJS platform that are really generating visits or navigation on the site and thereby detect possible SPAMMERS that are hindering the work.
Well, in terms of creating a PR, what I don’t know is the part of the PKP/OJS programming structure because basically following what is already done in the current matomo plugin and what they have done in the same plugin for Nextcloud is how to obtain the user ID or the username and pass it to the script in addition to putting in the configuration form if you want this variable to be activated, but hey that’s only objectively what should be done.
Topics/Sections are relevant because let others read your FR in a structured way.
If in future somebody needs to compile FR based on “who is asking for this feature” he/she only need to read this part of the post.
So please, if you don’t mind, would be great if you keep the section titles as in the template.
Releyendo tu post veo que hablas español y como es mi lengua materna, pues aprovecho que me cuesta menos.
Si le echas un ojo a las otras FR verás que no usamos las guidelines.
La idea es hacer que las peticiones sean uniformes para facilitar la lectura rápida, asà que con tu permiso (si no te convence, vuelve a la versión con guidelines que el post es tuyo), reedito tu post eliminando las guidelines en tu nombre.
