CUG pages are getting cached in Dispatcher

[Mayukh007]

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..?

[SureshDhulipudi]

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"

}

[Mayukh007]

It is caching any CUG page I am accessing in the site, not the login page. I can provide detail on my caching rules if you can point me to what you want me to look at..

[SureshDhulipudi]

Please provide the details , did you try with CUG page path deny in cache rules?

[Mayukh007]

HI Suresh, We allow everything for Dispatcher to cache. But as per CUG documentation, CUG pages are not cached by default unless we set "allowAuthorized 1" which makes sense as I dont know what will be path of CUG page in advance, any page can or can not be CUG set by Content Author on the Authoring Production. The only place we have "allowAuthorized" set as 1 is in Author farm files.

[SureshDhulipudi]

you are correct. allowAuthorized set to "0" should work. Can you check dispatcher logs and observe the farm getting invoked and rule applying, when you access the page

[Mayukh007]

I enabled Debug mode in dispatcher and ran the login steps. Here is what I see for my "cugpage" which is a CUG page and Dispatcher by default should not try to create cache for this 

domain/cugpage.html

xxxxxx :/mnt/var/log/httpd tail -f *.* | grep "cugpage"
[Thu Dec 03 18:28:29 2020] [D] [pid 10155] checking [/content/consumer-portal/en_CA/cugpage.html]
[Thu Dec 03 18:28:29 2020] [D] [pid 10155] cachefile does not exist: /mnt/var/www/html/content/consumer-portal/en_CA/cugpage.html
[Thu Dec 03 18:28:29 2020] [D] [pid 10155] try to create new cachefile: /mnt/var/www/html/content/consumer-portal/en_CA/cugpage.html
[Thu Dec 03 18:28:29 2020] [D] [pid 10155] cache-action for [/content/consumer-portal/en_CA/cugpage.html]: CREATE
[Thu Dec 03 18:28:29 2020] [D] [pid 10155] response.headers[Location] = "domain/libs/granite/core/content/login.html?resource=%2Fcontent%2Fconsumer-portal%2Fen_CA%2Fcugpage.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown"
[Thu Dec 03 18:28:29 2020] [I] [pid 10155] "GET /content/consumer-portal/en_CA/cugpage.html" 302 - 4ms [cugfarm/0]
[Thu Dec 03 18:28:29 2020] [D] [pid 10155] request contains a query string: resource=%2Fcontent%2Fconsumer-portal%2Fen_CA%2Fcugpage.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown
[Thu Dec 03 18:28:29 2020] [I] [pid 10155] "GET /libs/granite/core/content/login.html?resource=%2Fcontent%2Fconsumer-portal%2Fen_CA%2Fcugpage.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown" 200 12089 26ms [cugfarm/0]

Enter credential and hit login
[Thu Dec 03 18:30:17 2020] [D] [pid 10546] checking [/content/consumer-portal/en_CA/cugpage.html]
[Thu Dec 03 18:30:17 2020] [D] [pid 10546] cachefile does not exist: /mnt/var/www/html/content/consumer-portal/en_CA/cugpage.html
[Thu Dec 03 18:30:17 2020] [D] [pid 10546] try to create new cachefile: /mnt/var/www/html/content/consumer-portal/en_CA/cugpage.html
[Thu Dec 03 18:30:17 2020] [D] [pid 10546] cache-action for [/content/consumer-portal/en_CA/cugpage.html]: CREATE
[Thu Dec 03 18:30:18 2020] [D] [pid 10546] Cache file successfully created: /mnt/var/www/html/content/consumer-portal/en_CA/cugpage.html
[Thu Dec 03 18:30:18 2020] [I] [pid 10546] "GET /content/consumer-portal/en_CA/cugpage.html" - + 688ms [cugfarm/0]

[Jörg_Hoh]

When you use CUGs and want to cache protected content, you should use "Permission Sensitive Caching", see the documentation at https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/permissions-...

[Mayukh007]

Jörg_Hoh , I am not trying to cache CUG pages. My expectation is CUG pages by default never cache in Dispatcher, otherwise if it gets cached into Dispatcher the Authentication will not happen for next user onwards as Dispatcher will serve the page without checking the Authentication...My problem is my CUG pages getting cached and I dont want that to happen.

[Jörg_Hoh]

Hi,

by default the dispatcher does not cache any files, for which the request has certain "authentication" headers. That is an "authorization" header or a cookie "authorization" resp "login-token". If any of these are present, the dispatcher won't cache the files, unless you explicitly configure it to do so.

[Mayukh007]

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]

@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.

[Mayukh007]

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..?

[Mayukh007]

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...

[shelly-goel]

I think you've mixed up my response in another post Or the UI of discussions page is confusing (may be). I was asking you to check where the Cache-Control header is being set and see if it contains "public" or "always" in it.

[Mayukh007]

No, I think I posted in correct post in response to your question. "Cache-Control" is set in 2 of our custom farm files but it have no "public" or "always' in it as I posted above...

Even though i remove "Cache-Control" from there, it is still same behaviour.

But eventually I think I figured out where it is stemming from.

We are using "/auth_checker" in the farm file and commenting that one out resolving the issue...Need to dig more now... 

[Mayukh007]

I am still clueless why the "/auth_checker" is forcing to create dispatcher cache for CUG page. My CUG page is not in same filter where the "/auth_checker" filters are set...Does "/auth_checker" forces to create dispatcher cache if we are using same farm file where "/auth_checker" is implemented..?

I went through these articles:

https://www.argildx.com/technology/permission-sensitive-caching-psc/

https://helpx.adobe.com/ca/experience-manager/kb/PSCachingDelivery.html#samplecode

And as per this "/auth_checker" should work only on the filters I mention...