How to perform permission sensitive caching and it's use case? | Community
Skip to main content
Himanshu_Singhal
Himanshu_Singhal
New Participant
September 1, 2017
Solved

How to perform permission sensitive caching and it's use case?

  • September 1, 2017
  • 3 replies
  • 2740 views

Hi,

I'm exploring the "permission sensitive caching" of pages in AEM. I've followed the official documentation about how can we create a servlet to check user permissions and allow them to access cached pages.

But, what I didn't understand it how it'd be applied in the scenario?

Cos' so far whatever I've understood, 

1. To cache the authorised pages, we need to set the allowedAuthoried property value to 1 in the dispatcher. That allows us to cache authorised pages.

2. If we want to allow a website page to access from a particular group then we can enable the CUG feature so nobody apart from those developers would be able to access those pages.

3. Let's say if there's any login functionality on website and profile pages is getting cached so even if cached profile page is there in cache directory when we'll try to hit the user profile page URL directly, in any way it won't display if User is not logged in cos' that's what standard functionality says.

By keeping overall things in mind, I'm not able to make sense where "permission sensitive caching" comes in the scenario? What's the use of its explicit configuration?

Thanks,

Himanshu

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

    Hi

    The CUG feature is a feature of AEM; the dispatcher does not care about if access to a page is restricted or not. If you set /allowAuthorized "1" it will cache any page which matches the caching rule set.

    So if there is a CUG protected page /content/myprotectedpage.html, a logged-in user successfully accesses that page, the dispatcher can store it in cache. But what happens now, if an un-authorized user hits /content/myprotectedpage.html as well? It is stored in the dispatcher and the dispatcher delivers this page (as the dispatcher doesn't know about CUG and access control).

    So just using CUG is not enough if you want to cache protected pages.

    This is where the PSC comes into play. Before it delivers a page from the cache, it re-assures on the backend side, that it is ok to deliver that page from the cache. Then the dispatcher is permission-aware (although you can implement any kind of logic you like, not necessarily bound to the access control).

    Hope that helps,

    Jörg

    3 replies

    Himanshu_Singhal
    Himanshu_SinghalAuthor
    New Participant
    September 5, 2017

    Thanks @Jörg Hoh

    joerghoh
    joerghohAccepted solution
    Employee
    September 1, 2017

    Hi

    The CUG feature is a feature of AEM; the dispatcher does not care about if access to a page is restricted or not. If you set /allowAuthorized "1" it will cache any page which matches the caching rule set.

    So if there is a CUG protected page /content/myprotectedpage.html, a logged-in user successfully accesses that page, the dispatcher can store it in cache. But what happens now, if an un-authorized user hits /content/myprotectedpage.html as well? It is stored in the dispatcher and the dispatcher delivers this page (as the dispatcher doesn't know about CUG and access control).

    So just using CUG is not enough if you want to cache protected pages.

    This is where the PSC comes into play. Before it delivers a page from the cache, it re-assures on the backend side, that it is ok to deliver that page from the cache. Then the dispatcher is permission-aware (although you can implement any kind of logic you like, not necessarily bound to the access control).

    Hope that helps,

    Jörg

      kautuk_sahni
      kautuk_sahni
      Employee
      September 1, 2017

      Jörg Hoh​ your take here?

      ~kautuk

      Kautuk Sahni
      Terms & ConditionsAccessibility statement

      Loading footer...