Expand my Community achievements bar.

Enhance your AEM Assets & Boost Your Development: [AEM Gems | June 19, 2024] Improving the Developer Experience with New APIs and Events
SOLVED

Caching Secured Content issue

Avatar

Level 2

Hi Team,

 

We are using Caching Secured Content for protecting secured content, currently we are observing two issues

 

  1. It is working for pages but not for DAM (for /content/dam/.. servlet is not hitting)
    1. Not working in all Cloud servers.
    2. Working in few local systems not in few (same version, code and config).
  2. First time if we access the protected/secured page, request is not going via Auth Servlet (all users able to access), from second request (or refresh) it is working as expected (request is going via auth servlet).

Below is the auth checker config.

/auth_checker {
    # request is sent to this URL with '?uri=<page>' appended
    /url "/bin/securedcontentauth"

    # only the requested pages matching the filter section below are checked,
    # all other pages get delivered unchecked
    /filter {
        /0000 {
            /glob "*"
            /type "deny"
        }
        /0001 {
            /glob "/content/mysite/us/en/*private*"
            /type "allow"
        }
        /0002 {
            /glob "/content/dam/mysite/private/*"
            /type "allow"
        }
    }
    # any header line returned from the auth_checker's HEAD request matching
    # the section below will be returned as well
    /headers {
        /0000 {
            /glob "*"
            /type "deny"
        }
        /0001 {
            /glob "Set-Cookie:*"
            /type "allow"
        }
    }
}

 

 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @AG-AA 
Yes, you need to create a filter

For assets, it could be because of CDN cache. check if the assets are served from CN cache.



Arun Patidar

View solution in original post

6 Replies

Avatar

Community Advisor

Hello @AG-AA 

 

1. I hope you have disabled CDN caching for the "/content/dam/mysite/private/*"

Before you test for auth checker, please assure that the content is not already cached on CDN.

 

2. Also validate from an incognito window

 

3. If there are multiple dispatchers, request will hit only one dispatcher, hence you would see the logs also in one only

 

4. Assure that all the dispatchers have the same config.

 

5. Enable debug logs on dispatcher, is auth_checker is active, you should see log like 

AuthChecker: initialized with URL 'configured_url'.

6. Also, you would be able to better tail the logs.

Set DISP_LOG_LEVEL=debug in dispatcher for the same. Via Baseline variables tthat are predefined in the file conf.d/variables/global.vars. 

 


Aanchal Sikka

Avatar

Level 2

@aanchal-sikka 

Thanks for the reply.

  1. CDN cache is disabled. Cache-Control is set to Private.
  2. Validated in incognito and in multiple systems.
  3. Dispatcher and publish logs verified, request is going via auth_checker for pages but not for assets.
  4. Same config across.
  5. Yes, auth_checker is initialized and working for pages.

Avatar

Community Advisor

Hi @AG-AA 
1. You need to create a Filter to check the authentication when GET request hit publish.

2. You need to create a servlet to check the authentication when HEAD request hit publish.(e.g. /bin/securedcontentauth) -Done

3. For assets make sure you have performed check for all the assets type, if you are using cug to check access then you need to apply cug groups in all the assets subfolders

 



Arun Patidar

Avatar

Level 2

@arunpatidar 

Thanks for the reply.

  1. Not every request that matches the filter path will go via dispatcher auth check (HEAD request). Do we need to create filter again?
  2. Done
  3. For assets all types are allowed and Auth Check servlet is getting called in local, but not in cloud servers. Anything needs to be done specifically for cloud instance?

 

Avatar

Correct answer by
Community Advisor

Hi @AG-AA 
Yes, you need to create a filter

For assets, it could be because of CDN cache. check if the assets are served from CN cache.



Arun Patidar

Avatar

Administrator

@AG-AA  Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.



Kautuk Sahni