ResourceResolverFactory getServiceResourceResolver lanza una excepción en AEM 6.1

sling

Question

Quiero escribir algunos datos en AEM, y el siguiente código funciona bien para mí en AEM 6.0 pero no en AEM 6.1, siempre arroja una excepción de inicio de sesión de la siguiente manera:

" Excepción de inicio de sesión al obtener un usuario CRX para el Servicio: ''writeService''.org.apache.sling.api.resource.LoginException: No se puede derivar el nombre de usuario para el paquete group.tti.commons-service [395] y el sub servicio writeService "

Configuración OSGI:

Código en mi clase:

import javax.jcr.Session;
import org.apache.sling.api.resource.ResourceResolver;
import org.apache.sling.api.resource.ResourceResolverFactory;
....
@Reference
private ResourceResolverFactory factory;
private ResourceResolver resourceResolverWriter;
private static Session adminSession;
...
...
Map<String, Object> param = new HashMap<String, Object>();
param.put(ResourceResolverFactory.SUBSERVICE, "writeService");
try {
resourceResolverWriter = factory.getServiceResourceResolver(param);
adminSession = resourceResolverWriter.adaptTo(Session.class);
...
} catch (LoginException e) {
...
}

¿Me falta algo en AEM 6.1?

Answer 1

Además, si está planeando una futura migración a AEM 6.2, considere usar ACS Commons para facilitar la creación y disponibilidad de usuarios del sistema. Elimina todo este proceso manual que puede ser propenso a errores.

https://adobe-consulting-services.github.io/acs-aem-commons/features/ensure-service-users/index.html

Answer 2

Con el consejo de Justin, intenté y encontré la solución. Publicarlo puede ser beneficioso para otros.

Objetivo: escribir datos / nodos en el contenido (específicamente en / etc / userdata) cuando un usuario inicia sesión.

Podemos lograr esto de 2 maneras (de cualquier manera, el usuario debe ser un ''usuario del sistema'')

Proceso 1:

Paso 1: Use el usuario del sistema incorporado en la configuración OSGI. En OSGI, seleccione Apache Sling Service User Mapper Service

group.abc.commons-service:writeService=oauthservice (donde oauthservice es un usuario del sistema)

Paso 2: asigne a ese usuario del sistema los permisos para acceder a la carpeta de contenido.

Puede ver los usuarios del sistema en CRX en: /home/users/system

Proceso 2:

Paso 1 : Crea un nuevo usuario del sistema. para hacer esto Abra http://localhost:4502/crx/explorer/index.jsp

1. Login as admin
2. Open ''User Administration
3. Select ''Create System User''
4. Enter "user id"
5. Hit the Green button (you will not se a save button :)`

He creado un usuario abcwriteservice

Paso 2: vaya a Permisos y, para el usuario abcwriteservice, otorgue permisos para acceder a la carpeta donde desea escribir. (En este ejemplo: /etc/userdata )

Paso 3: Abra la consola OSGI y vaya al Servicio de mapeo de usuarios del servicio Apache Sling para definir la asignación del usuario del servicio.

Ejemplo: group.commons-service:writeService=abcwriteservice

Paso 4: en el código, agregué un parámetro adicional, como:

Map<String, Object> param = new HashMap<String, Object>();
param.put(ResourceResolverFactory.SUBSERVICE, "writeService");
try {
resourceResolverWriter = factory.getServiceResourceResolver(param);
if (resourceResolverWriter == null)
throw new Exception("Could not obtain a CRX User for the Service:''writeService''");
Node usersRootNode = adminSession.getNode("/etc/userdata/users");
}

Answer 3

En AEM 6.1, los usuarios del servicio deben ser usuarios del sistema, lo que significa que su nodo en el JCR es de tipo rep: SystemUser. Estos usuarios no pueden ser utilizados para iniciar sesión normalmente, solo por procesos en segundo plano. El usuario administrador no es un usuario del sistema, por lo que no puede utilizar el usuario administrador en un mapeo de usuarios de servicios como este. Debe crear un nuevo usuario del sistema y asignarles los permisos adecuados.

Si desea leer más sobre los antecedentes de este cambio, consulte https://issues.apache.org/jira/browse/SLING-3854 .

Answer 4

en lugar de hacer una sesión como:

adminSession = resourceResolverWriter.adaptTo(Session.class);`

haga la sesión como se muestra a continuación, esperemos que no ocurra una excepción

final Session session;
session= resourceResolver.adaptTo(Session.class);

Esto sucede porque resourceResolverWriter no es un objeto implícito.