La página no se almacena en caché y el usuario está autorizado
- Dispatcher determina que el contenido no se almacena en caché o que requiere una actualización.
- Dispatcher reenvía la solicitud original al procesador.
- El procesador llama al servlet AEM authorizer (que no es el servlet Dispatcher AuthChcker) para realizar una comprobación de seguridad. Cuando el usuario está autorizado, el procesamiento incluye la página representada en el cuerpo del mensaje de respuesta.
- Dispatcher reenvía la respuesta al explorador. Dispatcher añade el cuerpo del mensaje de respuesta del procesador a la caché.
El usuario no está autorizado
- Dispatcher comprueba la caché.
- Dispatcher envía un mensaje de solicitud al procesador que incluye todas las líneas de encabezado de la solicitud del explorador.
- El procesador llama al servlet Auth Checker para realizar una comprobación de seguridad que da error y el procesador reenvía la solicitud original a Dispatcher.
- Dispatcher reenvía la solicitud original al procesador.
- El procesador llama al servlet AEM authorizer (que no es el servlet Dispatcher AuthChcker) para realizar una comprobación de seguridad. Cuando el usuario está autorizado, el procesamiento incluye la página representada en el cuerpo del mensaje de respuesta.
- Dispatcher reenvía la respuesta al explorador. Dispatcher añade el cuerpo del mensaje de respuesta del procesador a la caché.
Implementar el almacenamiento en caché con permisos confidenciales
Para implementar el almacenamiento en caché que con permisos confidenciales, realice las siguientes tareas:
- Desarrollar un servlet que realice la autenticación y la autorización
- Configure Dispatcher
Header always set Cache-Control private
.Para AEM as a Cloud Service, consulte la página Almacenamiento en caché para obtener más información sobre cómo establecer encabezados de almacenamiento en caché privados.
Creación del servlet Auth Checker
Cree e implemente un servlet que realice la autenticación y la autorización del usuario que solicita el contenido web. El servlet puede utilizar cualquier autenticación. También puede utilizar cualquier método de autorización. Por ejemplo, puede utilizar la cuenta de usuario de AEM y las ACL del repositorio. O bien, puede utilizar un servicio de búsqueda LDAP. El servlet se implementa en la instancia de AEM que Dispatcher utiliza como procesador.
El servlet debe ser accesible para todos los usuarios. Por lo tanto, el servlet debe ampliar la clase org.apache.sling.api.servlets.SlingSafeMethodsServlet
, que proporciona acceso de solo lectura al sistema.
El servlet solo recibe solicitudes de HEAD del procesamiento, por lo que solo debe implementar el método doHead
.
El procesamiento incluye el URI del recurso solicitado como parámetro de la solicitud HTTP. Por ejemplo, se accede a un servlet de autorización a través de /bin/permissioncheck
. Para realizar una comprobación de seguridad en la página /content/geometrixx-outdoors/en.html, el procesamiento incluye la siguiente URL en la solicitud HTTP:
/bin/permissioncheck?uri=/content/geometrixx-outdoors/en.html
El mensaje de respuesta de servlet debe contener los siguientes códigos de estado HTTP:
- 200: Autenticación y autorización aprobadas.
El siguiente servlet de ejemplo obtiene la URL del recurso solicitado de la solicitud HTTP. El código utiliza la anotación Felix SCR Property
para establecer el valor de la propiedad sling.servlet.paths
en /bin/permimissioncheck. En el método doHead
, el servlet obtiene el objeto session y utiliza el método checkPermission
para determinar el código de respuesta adecuado.