Haven't found out the solution yet. As workaround, I am explicitly doing a redirect to 403 page from servlet if user does not have permission. Ideally, I wanted dispatcher to handle 403 correctly.

Tried the same logic on AEM cloud sandbox environment using the new project that I created using archtype 49. Was able to reproduce issue on sandbox as well. Attached were the files added/updated. Default.farm contains auth checkerdefault.vhost contains code for 403 and 500 page pathsValidateUserSer...

Hi Rohit, Thanks for taking a look at the problem.The first option you suggested is already tried out.The second option defeats the purpose of permission sensitive caching, so we can't implement it. We want content to be served from cache while auth checker validates permission from servlet.We tried...

We are using AEM cloud service and attempting to implement permission-sensitive caching. We have created an authentication checker servlet that verifies whether a user has access to a page or not. This servlet is functioning correctly and returns a 403 status code for unauthenticated users, as seen ...

Thanks @AMANATH_ULLAH and @iamnjain . That helped. I should have caught that one. Appreciate your response.If possible, just help me with one mystery, if the cache wasn't cleared properly. Why is it still that two users were seeing different content. Shouldn't both be seeing same cached content.

 We are trying to hit AEMaaCS(using fastly) URL from multiple locations and it seems all users are seeing different content of a page. User A is seeing CTA with text Cta 2 and User B is seeing CTA with text Cta 6, while the actual content should be showing CTA 7. Any idea what could be going wrong? ...

Sorry, I should have mentioned this is for AEM as a cloud service.

We have created environment variable named "ENV_TYPE" in cloud manager. When we are trying to use this variable in dispatcher code. The build is failing in code scan step.  Code below which makes use of env_type variable in dispatcher.Include /etc/httpd/conf.d/variables/org_$[env:ENV_TYPE].vars Logs...

Thanks, Albin. That solved the issue. Appreciate your inputs. 

Yep, all bundles are active. One observation was OSGI component for GraphqlClientImpl was appearing as Satisfied instead of active. Checked it via  developer console.Any idea why would the status go into  satisfied state?