Problem/Motivation
When visiting /admin/config/system/matomo and trying to configure the details tab "Roles", the roles don't appear.
Steps to reproduce
Go to /admin/config/system/matomo
Click on tab "Roles"
Proposed resolution
Since user_role_names has been removed in Drupal 11, an inline implementation should be implemented.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | Screenshot 2025-10-27 102431.png | 54.69 KB | hosterholz |
| #7 | Screenshot 2025-10-27 102312.png | 57.04 KB | hosterholz |
Issue fork matomo-3533416
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mmbkThis patch is nearly identically to https://www.drupal.org/project/matomo/issues/3537364 except the clean up the MatomoAdminSettingsForm.php.
I cannot decide which of these tickets to close as duplicate.Since the removed deprecated function in the settings form, this one should be prefered
Comment #4
hosterholzCommit 878205d4 unnecessarily removes HTML escaping.
\Drupal\Component\Utility\Html::escapeis not deprecated.user_role_nameswas used in 1.x not in 2.x. I see no extra benefit in the code changes toMatomoAdminSettingsForm.php, but potentially CSRF when role names containing HTML are displayed. This is a regression. So I close this issue as duplicate of #3537364 and reopen that issue.Comment #6
aporieHi hosterholz,
I guess you are talking about XSS injection more than CSRF.
It is not needed to escape your labels in the #options of a render element. Drupal's philosophy is "safe by default", and the render API (twig included) should render your labels without any potential HTML or javascript injections just fine.
Except if you voluntarily would append change the twig template to add
{{ checkbox|raw }}or use a Markup::create() in the #option, you should be safe.So the escape is not needed here and redundant.
Reopening. The maintainer will decide which fix is better for him.
Comment #7
hosterholzThank you for the clarification. I think another adjustment is needed.
If a group name containing HTML is created - e. g.
<img src="csrf">- HTML gets inserted with MR !77 applied.Issue #3554029 is related.
Unpatched
Role labels containing HTML are escaped.

Patched
Role labels containing HTML are not escaped. HTML is inserted.

Comment #8
aporieSo you have it.
It's Drupal default behavior: when HTML is inserted, it's rendered as plain text. There is no XSS injection possible.
Double escaping seems to render you a broken image, it's weird, and surely not the expected behavior.
That's why I included that in my patch, it's out of scope, but jumped out at me when I was fixing the Roles not being displayed.
If you have some time, you can:
- Close this ticket and keep the other one active.
- Open a new ticket to fix this double escaping, which produces an issue (as per your screenshot).
- And link things altogether to keep track record.
Comment #9
aporieOk, so I've been giving it a bit more time now that I'm home (was only reviewing, not testing).
I think you're absolutely right, and I've been wasting your time, sorry about that.
By default, (without HTML::escape) Drupal is safe regarding XSS injection, and I wasn't completely crazy to think that (a role with the name
<script>alert('Alert');</script>, won't work).Though, as you mentioned, it is subject to potential CSRF attack as is. The HTML::escape does the trick and prevent that. Of course, it is mitigated by the fact that you need a lot of permissions, but still. It is a security issue.
We can actually see it in : core/modules/filter/src/FilterFormatFormBase.php
And regarding #3554029: CSRF in Matomo Settings Form, it also looks to me a way to prevent CSRF and is a security issue.
I'm closing this ticket then.
Comment #10
aporieMR introduces a potential CSRF vulnerability.