Intermittent authoring issue in AEM

Correction - not the csrf toke is giving 403. it is the component dilaog submit post call giving 403.

Hi ​@MuhammadSa11 

You're right to focus on the login-token – that's the key here, not the token.json call.

From AEM's point of view, what's happening is:

• The user's AEM session cookie (login-token) is gone or not sent on the failing POST.
• The dialog submit is then treated as anonymous and hits the CSRF filter without a valid CSRF token > 403:

  com.adobe.granite.csrf.impl.CSRFFilter isValidRequest: empty CSRF token - rejecting
  com.adobe.granite.csrf.impl.CSRFFilter doFilter: the provided CSRF token is invalid
  org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration
  

  Navigation and opening dialogs still work because they're mostly GET requests and often cached/unprotected; only POST requires a valid login + CSRF token. The fact that:

• login-token is missing on the failing POST,

• it works in another browser, and

• it's fixed by clearing browser data and logging in again

all point to client‑side cookie/session state getting out of sync, not a broken CSRF implementation.

1. Fix for affected authors

Instead of "clear cache for all time", do a surgical reset:

• Open DevTools > Application/Storage >Cookies for your author URL (e.g. https://author.company.com).
• Delete only AEM/IMS cookies for that host, especially:
  • login-token
  • any oauth-configid / IMS cookies for that org
• Reload the author URL and log in once.

This is effectively the same as what you're doing now, but without wiping the whole browser cache.

2. Make sure authors always use one canonical author URL

The login-token cookie is host + path scoped. If people sometimes hit:

• https://author.company.com/
• https://author-vpn.company.local/
• https://10.x.x.x:4502/

they'll end up with multiple, incompatible sessions, and some requests (like the dialog POST) may go out without the cookie.

Pick one canonical author URL (usually the https://author… one) and:

• Communicate that to authors.
• Make sure any bookmarks / intranet links use only that host.

3. Check you haven't customized token/CSRF auth in a risky way

On the server side, keep the auth stack as close to default as possible:

• Token Authentication Handler (Granite Token Authentication Handler / TokenAuthenticationHandler):
• Cookie name should be login-token.
• Path should be /.
• SameSite should be left at the product default for your version unless Support explicitly told you otherwise (mis‑setting SameSite can cause modern browsers to silently drop the cookie).
• CSRF Filter: use the product defaults and make sure /libs/granite/csrf/token.json and the standard authoring POSTs are not blocked or cached by Dispatcher/CDN.

If you have custom OAuth/IMS/SAML auth handler configs, test once with all custom auth OSGi configs disabled (or in a lower env with stock auth) to confirm it's not a custom handler occasionally resetting or overwriting login-token.

If you can grab one HAR where the dialog POST fails and one where it succeeds, compare the Request Headers >Cookie line; you should see login-token present in the good case and missing in the bad one. That will give you something concrete to show infra/security if a proxy, extension, or SSO tweak is stripping or rewriting cookies.