AEM Gated Pages Caching Strategies

PublishedMarch 21, 2024

Viewed205 times

In General, requests containing authentication information are not cached because the cached document is served to the client without authentication. However, if the requirements permit the caching of authenticated documents, this can be activated by setting the /allowAuthorized property to "1". Additionally, need to implement the /auth_checker module, which verifies users access permissions for a page before delivering the cached content.

Enable Caching for AEM Gated Pages

By default, the /allowAuthorized property in AEM Dispatcher controls whether requests containing certain authentication information are cached. This includes data from the authorization header, as well as cookies named "authorization" and "login-token". Typically, such authenticated requests are not cached to prevent serving cached content to users without the necessary permissions. However, based on the requirements, Enabling caching for gated pages can be achieved with the following configuration.

publish_farm.any

/cache {
  ## caches authorized data
  /allowAuthorized "1"
}

Subsequently, configure the /auth_checker module to validate user access permissions for the page prior to delivering the cached content. Otherwise, once a page is cached, no further authorization is required for users to view it.

Auth Checker Dispatcher Configuration

The /auth_checker section of the dispatcher.any file controls permission-sensitive caching behavior. It comprises the following subsections:

url: Defines the value of the servlet paths for the servlet responsible for user access permission checks.
filter: Filters that specify the content path where permission-sensitive caching is applied. Usually, a deny filter is applied to all paths, while allow filters are used for secured content paths.
headers: Specifies the HTTP headers included in the response by the authorization servlet.

publish_farm.any

/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/aem-demo/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"
    }
  }
}

The servlet specified in the url section fetches the URL of the requested resource from the HTTP request. Within its doHead method, the servlet obtains the session object and utilizes the checkPermission method to determine the appropriate response code.

AuthCheckerServlet.java

@Component(service = { Servlet.class })
@SlingServletPaths("/bin/permissionCheck")
public class AuthServlet extends SlingSafeMethodsServlet {
  private final Logger LOG = LoggerFactory.getLogger(AuthCheckerServlet.class);

  @Override
  public void doHead(SlingHttpServletRequest request, SlingHttpServletResponse response) {
    String uri = request.getParameter("uri");
    Session session = request.getResourceResolver().adaptTo(Session.class);

    try {
      session.checkPermission(uri, Session.ACTION_READ);
      LOG.info("AuthChecker READ Access OK for {}", uri);
      response.setStatus(SlingHttpServletResponse.SC_OK);
    } catch (RepositoryException e) {
      LOG.info("AuthChecker READ Access FORBIDDEN for {}", uri);
      response.setStatus(SlingHttpServletResponse.SC_FORBIDDEN);
    }
  }
}

When users are authorized, indicated by 200 OK status code, the page may either be served from cache or regenerated if needed. However, if unauthorized, denoted by a 403 Forbidden status code, the request is routed to the publish instance, where the user is prompted to log in before accessing the gated page.

After configuring caching for gated pages, four potential scenarios may arise when attempting to access them.

Page is cached and User is authorized
Page is cached and User is not authorized
Page is not cached and User is not authorized
Page is not cached and User is authorized

The following diagrams illustrate the sequence of events that take place when a web browser requests a page utilizing permission-sensitive caching.

Web Browser request for a gated page that matches the URLs configured in the auth_checker filter.
Dispatcher verifies if the requested page is cached.
If page is cached:
1. Publisher validates user permission via AuthServlet.
2. If permission granted, Dispatcher deliver cached content.
If page is not cached:
1. Dispatcher forwards request to publisher.
2. Publisher checks user authorization.
3. If authorized, generates HTML, caches content, and delivers.
If unauthorized:
1. User redirected to login page.
2. Upon successful login, redirected to gated page, restarting process from step 1.