Support token_auth with higher access for configurable Module.Action endpoints

[mneudert]

Description

Requesting a non-API endpoint in Matomo using a regular token_auth is, by default, only allowed with a "view only" access backed account. For higher privileges required activating enable_framed_allow_write_admin_token_auth:

matomo/config/global.ini.php

Lines 553 to 558 in 5634dff

	; Set to 1 to allow using token_auths with write or admin access in iframes that embed Matomo.
	; Note that the token used will be in the URL in the iframe, and thus will be stored in webserver
	; logs and possibly other places. Using write or admin token_auths can be seen as a security risk,
	; though it can be necessary in some use cases. We do not recommend enabling this setting, for more
	; information view the FAQ: https://matomo.org/faq/troubleshooting/faq_147/
	enable_framed_allow_write_admin_token_auth = 0

This is a global setting, for everything, and cannot be limited to certain plugins if one wants to keep the risk low.

This PR adds a new config option with a naming not specifically tied to "framed pages", that allows configuring a list of Module.Action endpoints to be accessible by token_auth. Might need some future improvements to adjust the error message, as that always hints at the widgetization/embedding, but might be useful for any controller that needs token authentication and does not fit in the API layer.

It still keeps the super user access guard in place. Only write/admin level tokens are possible.

Checklist

• [✔] I have understood, reviewed, and tested all AI outputs before use
• [✔] All AI instructions respect security, IP, and privacy rules

Review

• Functional review done
• Potential edge cases thought about (behaviour of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• New documentation added or existing documentation updated