Dispatcher doesn't respect group membership restriction | Community
Skip to main content
C
chetanvajre2014
Level 4
October 16, 2015
Solved

Dispatcher doesn't respect group membership restriction

  • October 16, 2015
  • 11 replies
  • 2468 views

We have a page say users.html which is only visible to group "admin" and is configured in the author instance. The site can have both protected and open pages (anonymous allowed). Issue is, when a user from the "admin" group visits the page, the dispatcher caches user.html and then if any anonymous user requests it, it returns that page without authorization.

ONe way was to include that page under the dispatcher.any file. But authors keep creating these pages and we cannot expect to keep restarting dispatcher. I would've assumed the product is smart to respect the restriction, else for such a site that has a mixture of authenticated and non-authenticated pages, this is a maintainence nightmare.

Is there a setting to make sure dispatcher respects the page authorization?

    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 JustinEd3

    Hi,

    Let's assume that allowAuthorized is 0, is configured to cache *.html, the dispatcher cache is initially empty, Permission Sensitive Caching is *not* enabled.

    User requests Page A (/pagea.html). They are anonymous. The dispatcher looks and sees that the page is not cached so it goes and makes a request to AEM. AEM responds with a 200 status code. The dispatcher thus caches the page and returns it to the user.

    User requests to Page B (/pageb.html). They are *still* anonymous. The dispatcher looks and sees that the page is not cached so it goes and makes a request to AEM. AEM responds with a 302 status code redirecting the user to the login page. The dispatcher doesn't cache redirects, so it just returns the 302 to the user.

    User logs in by sending a POST request. The login works and they are redirected to Page B. The dispatcher will never cache responses to POST requests, so it just is a pass through here.

    User now requests Page B. Their request contains a login-token cookie. The dispatcher sees this cookie and sends the request to AEM. AEM responds with a 200 status code (because the user can now see the page). Because the request had a login-token cookie, the dispatcher does not cache this response.

    User (still logged in) now requests Page A. Because the request contains authorization, even though the page is in the dispatcher's cache, the cached page is not served directly and instead a request is made to AEM. AEM responds with a 200 status code. The dispatcher returns this response to the user; the cache is not touched (because the request has the login-token cookie).

    IIOW - only responses to anonymous users are cached and authenticated users never get cached content.

    HTH,

    Justin

    11 replies

    P
    PaulMcMahon
    Level 8
    October 16, 2015

    Dispatcher does not handle this by default. There are multiple ways of dealing with the problem but the cleanest way, and the method that the product supports best is Closed User Groups. 

    See http://docs.adobe.com/docs/en/aem/6-0/administer/security/cug.html for documentation. 

    Also see http://www.slideshare.net/evolve_conference/evolve13-enhance-26102078 for step by step implementation involving dispatcher and permission sensitive caching. 

      J
      Adobe Employee
      JustinEd3Adobe Employee
      Adobe Employee
      October 16, 2015

      FWIW, the dispatcher does handle this scenario by default. When the allowAuthorized flag is 0 (the default), if the request contains authorization information (either the HTTP Authorization header or a login-token cookie) then the response will not be cached. This ensures by default that authorized content is never served to anonymous users.

      Permission Sensitive Caching allows you to fine tune this behavior so that *some* authorized content can be cached.

      Justin

      S
      Sam205505050
      Level 6
      October 16, 2015

      Permission sensitive caching is perfect for this problem as pointed out by orotas. For more details -

      http://helpx.adobe.com/experience-manager/kb/PSCachingDelivery.html

      C
      chetanvajre2014Author
      Level 4
      October 16, 2015

      Justin,

       

      Thanks. Actually Adobe consultants ended up implementing permission sensitive caching for us. We found that inconvenient as every page that needed "not" to be cached had to have entered there. Are you suggesting there is no need to do it and instead just have allowAuthorized 0 and it should take care of it? If we switch the page from CUG to open and vice versa, the caching would be automatically adjusted?

       

      Again, appreciate all your responses

      C
      chetanvajre2014Author
      Level 4
      October 16, 2015

      Justin

      Great to know this is by default. Actually Adobe is implementing CQ at our project, wonder how that's not working - we would assume Adobe consultants would best know this. BTW, I am getting my feet wet on this one, can you tell me where to set this flag? On dispatcher config? Any link would work fine.

      J
      Adobe Employee
      JustinEd3Adobe Employee
      Adobe Employee
      October 16, 2015

      Hi,

      It isn't entirely clear to me what you are trying to accomplish. Your original post said that this was the issue: "Issue is, when a user from the "admin" group visits the page, the dispatcher caches user.html and then if any anonymous user requests it, it returns that page without authorization.". If allowAuthorized is 0, this would never happen as the response for an authenticated user would never be cached.

      Now it sounds like like you want to do partial caching of authenticated content -- meaning that you want it to be cached, but only delivered if the user has the appropriate permissions. For this, Permission Sensitive Caching is absolutely the correct approach. The issue you are describing around configuration seems to be an implementation choice in how the servlet side of Permission Sensitive Caching was implemented. You'd have to talk to your implementation team about that - it is possible for that servlet to detect the currently configured CUG Roots, although the way you have to do this is a bit roundabout.

      Regards,

      Justin

      C
      chetanvajre2014Author
      Level 4
      October 16, 2015

      Justin,
      sorry for confusion. We DO NOT want to do partial caching, we were told by consultants that this was the ONLY way to achieve no cache for CUG pages. Apparently, that's not true. Setting it to 0 should've accomplished that.

      Thanks for your help.

      J
      Adobe Employee
      JustinEd3Adobe Employee
      Adobe Employee
      October 16, 2015

      Just to be clear, if you set allowAuthorized to 0 nothing will be cached for authorized users. It isn't just CUG pages. It would impact all pages.

      C
      chetanvajre2014Author
      Level 4
      October 16, 2015

      Justin,

      Lets take an example:

      Page A - Should be open to all (authorized, unauthorized)

      Page B - Is protected by CUG say Role 1 Role 2

      We want Page B is not cached on dispatcher (obviously else anonymous user would be able to see it). Is this functionality available OOB by setting that flag to 0?

      The consultants told us the ONLY way to do this is put the Page B path in dispatcher.any file. We thought that would be a nightmare as I can create Page C tomorrow with CUG and i would have to make an entry for that in dispatcher.any -

      Again, such a great help , thanks in advance.

      J
      Adobe Employee
      JustinEd3Adobe EmployeeAccepted solution
      Adobe Employee
      October 16, 2015

      Hi,

      Let's assume that allowAuthorized is 0, is configured to cache *.html, the dispatcher cache is initially empty, Permission Sensitive Caching is *not* enabled.

      User requests Page A (/pagea.html). They are anonymous. The dispatcher looks and sees that the page is not cached so it goes and makes a request to AEM. AEM responds with a 200 status code. The dispatcher thus caches the page and returns it to the user.

      User requests to Page B (/pageb.html). They are *still* anonymous. The dispatcher looks and sees that the page is not cached so it goes and makes a request to AEM. AEM responds with a 302 status code redirecting the user to the login page. The dispatcher doesn't cache redirects, so it just returns the 302 to the user.

      User logs in by sending a POST request. The login works and they are redirected to Page B. The dispatcher will never cache responses to POST requests, so it just is a pass through here.

      User now requests Page B. Their request contains a login-token cookie. The dispatcher sees this cookie and sends the request to AEM. AEM responds with a 200 status code (because the user can now see the page). Because the request had a login-token cookie, the dispatcher does not cache this response.

      User (still logged in) now requests Page A. Because the request contains authorization, even though the page is in the dispatcher's cache, the cached page is not served directly and instead a request is made to AEM. AEM responds with a 200 status code. The dispatcher returns this response to the user; the cache is not touched (because the request has the login-token cookie).

      IIOW - only responses to anonymous users are cached and authenticated users never get cached content.

      HTH,

      Justin

      Show more replies
      Terms & ConditionsAccessibility statement

      Loading footer...