CUG pages are getting cached in Dispatcher | Community
Skip to main content
M
Mayukh007
Level 4
December 2, 2020

CUG pages are getting cached in Dispatcher

  • December 2, 2020
  • 2 replies
  • 3784 views

HI,

 

We are at AEM 6.5.5, running deployments using Adobe Cloud Manager.

We are trying to implement CUG (Closed User Group) but I am seeing 2 new issues which I did not see when I first tried CUG 8/9 months back.

 

1. Could not login to CUG page using Dispatcher URL and was getting error at "/libs/granite/core/content/login.html/j_security_check".

Had to add this rule in Dispatcher to get this resolved.

 

File name - publish-filter-after.any
Rule - /0065 { /type "allow" /glob "*j_security_check*" }

 

2. Now I find that CUG pages getting automatically cached in Dispatcher which it should not and thus after first user logs in, from next user onwards Dispatcher is serving the cached page, making CUG authentication irrelevant...User is no longer getting challenged for Authentication.

 

These are 2 entire new things I am seeing now which was not like that before...

Does anyone have any pointer..?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

2 replies

SureshDhulipudi
Community Advisor
SureshDhulipudiCommunity Advisor
Community Advisor
December 3, 2020

did you check your cache rules?

you can deny cache of this page

 

## Don't cache login token or pages

/0220 {

 /glob "/libs/granite/core/content/login*"

/type "deny"

}

    M
    Mayukh007Author
    Level 4
    December 10, 2020

    Thank you for the solution @sureshdhulipudi ....that works like charm...should have thought of that.. what I think happening for auth_checker is a design flaw...Dispatcher is creating cache file first and then doing validation...which to me should be otherway...

     

    But yes, this will work...

     

    Thanks again.

    shelly-goel
    Adobe Employee
    shelly-goelAdobe Employee
    Adobe Employee
    December 5, 2020

    @mayukh007  Please check if the cache-control header is being set as 'always' or with additional parameters like 'public'. These might be overriding the non-cache behavior for secure pages.

    M
    Mayukh007Author
    Level 4
    December 7, 2020

    Thank you @shelly-goel  for your pointer.

     

    I checked one of the domain where it is always creating cache, and I found this in the farm file of that domain:

     

    ## Cache response headers next to a cached file. On the first request to
    ## an uncached resource, all headers matching one of the values found here
    ## are stored in a separate file, next to the cache file. On subsequent
    ## requests to the cached resource, the stored headers are added to the
    ## response.
    ## Note, that file globbing characters are not allowed here.
    /headers {
    "Cache-Control"
    "Content-Disposition"
    "Content-Type"
    "Expires"
    "Last-Modified"
    "X-Content-Type-Options"
    "MLI_HasEntitlementContainer"
    "MLI_Private"
    }
    }
     
    Whereas I tested all other domains which doe snot have this "/header" set, and they dont cache CUG page.
     
    So is it the "/header" property which is causing this or "Cache-Control" property there..?
      M
      Mayukh007Author
      Level 4
      December 7, 2020

      Hmm...even after remove entire /header section it still creates cache file for CUG page. It just stopped creating .h (header cache files) files.

       

      So issue exists...

        Terms & ConditionsAccessibility statement

        Loading footer...