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..?
Views
Replies
Total Likes
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"
}
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]
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.
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.
Views
Replies
Total Likes
@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.
Views
Replies
Total Likes
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:
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...
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.
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...
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...