Repository tools do not set session/csrf cookies

[AFaust]

BUG

Expected behavior

The Administration Console tools added to the Repository by OOTBee Support Tools should act similar to the default tools when their page is being loaded. The HTML response for the default tools includes setting session and csrf cookies. The OOTBee Support Tools pages should do the same.

Actual behavior

Under a particular customer setup (ACS 7.3.1 + OOTBee Support Tools 1.2.2.0), the OOTBee Support Tools pages currently do not set session or csrf cookies, which can lead to HTTP 403 errors for XHR calls to the backend.

Steps to reproduce the behavior

• access "System Information" tool
• delete current cookies via browser Developer Tools
• reload tool via browser refresh
• check request/response in Developer Tools, specifically presence of Set-Cookie -> reload contains no session / CSRF cookie
• repeat previous steps with any default tool -> reload contains new session / CSRF cookie

I was thus far not able to reproduce the spurious 403 error from the customer environment in a clean ACS setup.

Additional details (analysis so far, log statements, references, etc.)

The CSRF cookie is not created because the default CSRFPolicy configuration only includes rules for the default admin console base URLs, not a generic rule for "any web script". As a result, our web scripts are excluded. When the OOTBee Support Tools was created (using Alfresco 5.0.d/5.1), no CSRFPolicy configuration existed - this seems to have been added later in Enterprise 5.1.N/5.2.1, and then found its way into Community.
Not only does the CSRFPolicy not contain a rule for generic web scripts, but the web.xml also does not contain a mapping for the CSRFFilter to work on anything else but the default Admin Console web scripts. And it is the filter as well which force-creates the HTTP session before checking the CSRF rule set, even though the comment in the configuration states that a session would only be created IF a CSRF rule path matches.

In order to fix this behaviour for the OOTBee Support Tools, we would have to add a web-fragment.xml to expand the CSRFFilter to our web scripts and add a web.config source URL to load a config file for our module (without abusing the default extension path).
On the other hand, since the filter is not covering our URLs, we technically should not encounter any errors due to CSRF cookie logic. As a result we may not have to do anything.

Tell us about your environment

TBD

[AFaust]

A big challenge with using a web-fragment.xml to enable session/CSRF cookie for OOTBee Support Tools is the switch from Java EE to Jakarta in ACS 23.x and onwards. It is unclear whether a web-fragment.xml that uses the XML namespace for Java EE would still be processed by Jakarta.
An additional challenge is that adding the org.springframework.extensions.webscripts.servlet.CSRFFilter will update the minimal compatible version of the ACS repository to a version which includes a spring-webscripts JAR of version 6.11 or newer. While we already compile against ACS 6.1.2 which includes version 6.20, we currently state to be compatible with ACS 5.0.d, which surely used an older version of Spring WebScripts. For this reason alone, this bugfix cannot be included in any 1.2.3.x version of the OOTBee Support Tools