Dispatcher Returning Incorrect Status(200 instead of 403) for Secure Pages in AEM Cloud Service | Community
Skip to main content
A
akash_mca2008
Level 2
May 24, 2024

Dispatcher Returning Incorrect Status(200 instead of 403) for Secure Pages in AEM Cloud Service

  • May 24, 2024
  • 3 replies
  • 947 views

We are using AEM cloud service and attempting to implement permission-sensitive caching. We have created an authentication checker servlet that verifies whether a user has access to a page or not. This servlet is functioning correctly and returns a 403 status code for unauthenticated users, as seen in the request.log.

We have also properly configured the dispatcher authentication checker, including setting the servlet URL and filter path to restrict access. Additionally, CDN caching has been disabled.

The problem arises when the dispatcher log returns a 200 status for secure pages, even though the publisher returns a 403 status based on the publisher log. We are able to view the secure page even when logged in as an unauthenticated user.

The provided code is an example of what we have written in the dispatcher to return a 403 status. We are unsure if this code is supported in AEM cloud. We are experiencing similar issues with the 500 error page as well, although the 404 page is functioning correctly. It seems that Apache is unable to redirect to the 403 and 500 error pages, despite the publisher returning the correct status.

 

We have been reading this document and are wondering if the CDN configuration is necessary for the 403 and 500 error pages.

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/content-delivery/cdn-error-pages#sample-generated-html

#Disabling cdn cache for secure pages
<LocationMatch "/content/site/secure/.*\.(html)$">
Header unset Cache-Control
    Header unset Expires
Header always set Cache-Control "private"
    Header always set Surrogate-Control "max-age=0,stale-while-revalidate=0,stale-if-error=0"
</LocationMatch>
 
//Retrn 403 pages
ErrorDocument 404 /content/gwc/en-US/404-page.html
ErrorDocument 403 /content/site/403-error.html
 
#Auth Checker Dispatcher configs
/auth_checker
{
# request is sent to this URL with '?uri=<page>' appended
/url "/bin/permissioncheck"
 
# 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/site/secure/*.html"
/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"
}
}
}
    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

    3 replies

    Rohan_Garg
    Community Advisor
    Rohan_GargCommunity Advisor
    Community Advisor
    May 24, 2024

    When the AEM Dispatcher returns a 200 status code for secure pages, even though the AEM Publish instance correctly returns a 403 status code, it indicates that the Dispatcher might be serving cached content without properly checking authentication or authorization.

     

    Can you try the below changes?

    1. Enable Authentication Checker - 

    /dispatcher {
    /auth_checker {
    /url "/libs/granite/authentication/authorize" or /url "/bin/permissioncheck"
    /filter {
    /0000 { /url "/content/secure/*" /type "allow" }
    }
    }
    }

     

    2. Avoid Caching Secure Pages - 

    /cache {
    /rules {
    /0000 { /glob "*" /type "deny" }
    /0001 { /glob "/content/secure/*" /type "deny" }
    /0002 { /glob "/content/*" /type "allow" }
    }

    /headers {
    "Authorization"
    "Cookie"
    }

    /invalidate {
    /0000 { /glob "*" }
    }
    }

    @akash_mca2008 - Can you check if you are denying cache set for /content/site/secure/*.html?

     

    3. Set HTTP Headers to Control Caching

    The Cache-Control header should be set to "no-cache, no-store, must-revalidate"

    I noticed your cache-control is setting max-age to 0. Can you try setting to no-cache?

    Caches may sometimes choose to use a stale response (although I believe they have to then add a Warning header), but no-cache says they're not allowed to use a stale response no matter what.

      A
      akash_mca2008Author
      Level 2
      May 25, 2024

      Hi Rohit,

       

      Thanks for taking a look at the problem.

      The first option you suggested is already tried out.

      The second option defeats the purpose of permission sensitive caching, so we can't implement it. We want content to be served from cache while auth checker validates permission from servlet.

      We tried third option, but that didn't help.

       

      As mentioned earlier, I don't think problem is with permission sensitive caching(auth checker), but instead problem seems to be with 403 and 500 status in aem cloud. It seems like dispatcher in AEM cloud is not able to interpret 403 and 500 status returned by publisher. However, 404 status works absolutely fine.

       
        A
        akash_mca2008Author
        Level 2
        May 25, 2024

        Tried the same logic on AEM cloud sandbox environment using the new project that I created using archtype 49. Was able to reproduce issue on sandbox as well. Attached were the files added/updated.

         

        Default.farm contains auth checker

        default.vhost contains code for 403 and 500 page paths

        ValidateUserServlet contains logic to return 200 or 403 based on simple condition

         

         

         

          kautuk_sahni
          Community Manager
          kautuk_sahniCommunity Manager
          Community Manager
          June 10, 2024

          @akash_mca2008 Did you find the suggestion helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!

          Kautuk Sahni
          A
          akash_mca2008Author
          Level 2
          June 10, 2024

          Haven't found out the solution yet. As workaround, I am explicitly doing a redirect to 403 page from servlet if user does not have permission. Ideally, I wanted dispatcher to handle 403 correctly.

            Terms & ConditionsAccessibility statement

            Loading footer...