Hi,
After we enabled SAML authentication, all our post calls were failing with 403.
We resolved it by adding "granite.csrf.standalone" clientlib into template level.
But now in EDGE browser, after some idle time, CSRF token generation API(/libs/granite/csrf/token.json_ loading from Edge browser cache and not giving actual token as response.
Because of this all POST calls are failing with 403 until we clear cache manually.
Is there any way we can block this API loading from Disc cache(Browser) ?
Response:
Post Call:
Expected Response:
Solved! Go to Solution.
Views
Replies
Total Likes
Thanks @aanchal-sikka for the information.
Actually, when it was loading from server no-cache was available for cache-control.
But when it is loading from disc it was not available.
And we have fixed the issue now.
Root Cause:
The issue appears to be caused by token.json file cached on the nodes where the issue is observed We have added the rule to disable caching of token.json on publish dispatchers and removed the cached file.
/0003
{
#Deny caching of CSRF token.json
/glob "/libs/granite/csrf/token.json"
/type "deny"
}
token.json cache was available for few dispatchers and it caused the issue. Post clearing dispatcher cache under /srv/www/cache/publish/libs/granite/csrf' resolved the issue.
Hi @akhilraj ,
You could make use of cache configuration to control it for specific path(s).
Cache-Control: no-cache
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
Also, validate dispatcher configuration.
Under the /cache /rules section of your publish-farm.any, add a rule to block the dispatcher from caching the token.json file.
Hope this helps!
Regards,
Nitesh
Hi @nitesh_kumar ,
We have this configuration already present.
But in EDGE browser after some time out, then it is loading from Browser cache only. and not giving proper response
Hi @somen-sarkar ,
issue is available in Chrome as well
If we uncheck Disable cache, it is loading from disc cache. But in lower environment it is always getting data from Server.
Hello @akhilraj
Can you please verify the value of Cache-control header in the request? For us, its set as no-cache and its not loaded from disk cache
- Do you have an AEM 6.5 or a Cloud Instance?
- If Cloud, could you have possibly used
Define DISABLE_DEFAULT_CACHING
Please try setting the Cache-control header as nocache and check.
Thanks @aanchal-sikka for the information.
Actually, when it was loading from server no-cache was available for cache-control.
But when it is loading from disc it was not available.
And we have fixed the issue now.
Root Cause:
The issue appears to be caused by token.json file cached on the nodes where the issue is observed We have added the rule to disable caching of token.json on publish dispatchers and removed the cached file.
/0003
{
#Deny caching of CSRF token.json
/glob "/libs/granite/csrf/token.json"
/type "deny"
}
token.json cache was available for few dispatchers and it caused the issue. Post clearing dispatcher cache under /srv/www/cache/publish/libs/granite/csrf' resolved the issue.
Hello @akhilraj
requesting you to please validate if all configurations are done as per https://github.com/AdobeDocs/experience-manager-dispatcher.en/blob/main/help/using/configuring-dispa...
You can also exclude paths for validation using the approach suggested on https://www.albinsblog.com/2023/03/what-is-csrf-how-is-csrf-protection-enabled-in-aem.html
Same we enabled in lower environment and verifying
Views
Likes
Replies
Views
Likes
Replies