Issue Description
The customer, Scotiabank, has reported a significant performance concern due to over 1.3 million requests per day to the URL /libs/granite/csrf/token.json on their AEM publisher. These requests include a "no-cache" attribute, exacerbating performance issues. The customer is unclear about what triggers these requests, especially since they occur on anonymous pages, and is seeking assistance in identifying the root cause and potential mitigation strategies.
Steps to Reproduce
The customer replicated the issue locally by cloning the WKND project and building it on their laptop. When a page at http://localhost:4503/content/wknd/ca/en.html is opened, it makes a call to /libs/granite/csrf/token.json. They also created a blank template from the WKND project, resulting in the same CSRF token request.
Investigation by Support
It was identified that the CSRF token request is initiated by a container script in the customer's setup, unlike the WKND project where the request is made by jQuery. Suggestions include testing different configurations to potentially mitigate these requests.
the csrf JS(granite.csrf.standalone) file is getting added as a dependency from core.wcm.components.form.container.v2 component. We also identified that clientlib-base is embedding this dependency. After removing the form container reference from clientlib-base, csrf js file stopped getting added on the page. We can update the clientlib-base to exclude core.wcm.components.form.container.v2 from our codebase.
Logs and Findings
The investigation uncovered that the CSRF token requests are essential for authenticated users but for anonymous pages, they return minimal payloads. This behavior, especially without caching, contributes to slower performance. The customer has attempted removing dependencies related to forms, which are suspected of triggering these requests, yet the issue persists.
Customer Impact
The high frequency of non-cacheable CSRF token requests is contributing to slower performance on the site. This is a major concern given the volume of requests and the impact on both authenticated and anonymous users. The customer seeks a deeper understanding and potential adjustments to the configuration or implementation to mitigate the impact.
What we need from the ticket:
Let us know is there a way to get the csrf.js file added on the pages where Form Container is used. If not, Do you have any other recommendations?
steps to reproduce:
1] create a project using the latest archetype.
2] see the CSRF getting called on pages via a clientlib js.
Issue Description The customer, Scotiabank, has reported a significant performance concern due to over 1.3 million requests per day to the URL
/libs/granite/csrf/token.jsonon their AEM publisher. These requests include a "no-cache" attribute, exacerbating performance issues. The customer is unclear about what triggers these requests, especially since they occur on anonymous pages, and is seeking assistance in identifying the root cause and potential mitigation strategies.Steps to Reproduce The customer replicated the issue locally by cloning the WKND project and building it on their laptop. When a page at
http://localhost:4503/content/wknd/ca/en.htmlis opened, it makes a call to/libs/granite/csrf/token.json. They also created a blank template from the WKND project, resulting in the same CSRF token request.Investigation by Support It was identified that the CSRF token request is initiated by a container script in the customer's setup, unlike the WKND project where the request is made by jQuery. Suggestions include testing different configurations to potentially mitigate these requests.
the csrf JS(granite.csrf.standalone) file is getting added as a dependency from core.wcm.components.form.container.v2 component. We also identified that clientlib-base is embedding this dependency. After removing the form container reference from clientlib-base, csrf js file stopped getting added on the page. We can update the clientlib-base to exclude core.wcm.components.form.container.v2 from our codebase.
Logs and Findings The investigation uncovered that the CSRF token requests are essential for authenticated users but for anonymous pages, they return minimal payloads. This behavior, especially without caching, contributes to slower performance. The customer has attempted removing dependencies related to forms, which are suspected of triggering these requests, yet the issue persists.
Customer Impact The high frequency of non-cacheable CSRF token requests is contributing to slower performance on the site. This is a major concern given the volume of requests and the impact on both authenticated and anonymous users. The customer seeks a deeper understanding and potential adjustments to the configuration or implementation to mitigate the impact.
What we need from the ticket:
Let us know is there a way to get the csrf.js file added on the pages where Form Container is used. If not, Do you have any other recommendations?
steps to reproduce: 1] create a project using the latest archetype. 2] see the CSRF getting called on pages via a clientlib js.