Ir al contenido principal

Error en ejecución de script en Alfresco

Hace tiempo publiqué una entrada con una serie de webscripts para facilitar ciertas tareas de administración de Alfresco: Pantalla de Administración para Alfresco.

Pues hace poco tuve que cambiar el tipo de autenticación en uno de los webscripts para permitir su uso a usuarios no adminstradores, para ellos cambié la autenticación a user. Fué entonces cuando surgió el problema. Para ciertos grupos, al lanzar el script me devolvía el siguiente mensaje:

500 Description: Un error en el servidor HTTP, el cual le ha impedido cumplir con la solicitud.

Message: 09246007631 Wrapped Exception (with status template): 09246007630 Failed to execute script '/org/alfresco/sample/prueba.post.js (in repository store workspace://SpacesStore/Empresa/Diccionario de datos/Web Scripts)': 09246007629 Acceso denegado. No tiene los permisos apropiados para realizar esta operación.

Exception: net.sf.acegisecurity.AccessDeniedException - Access Denied

Traceando el script me dí cuenta que el error se obtenía en el método: 
 lista = people.getMembers(grupoObtenido, false);

Comparando grupos en los que me daba el error encontré un usuario en común. Al quitar dicho usuario del grupo, el script volvía a correr adecuadamente. Por tanto el error lo estaba provocando dicho usuario.

Pasé a investigar las propiedades de dicho usuario a través del explorador de nodos y me percaté que el usuario poseía un permiso que el resto no tenía:
All ROLE_OWNER ALLOWED

Al tener el ROLE_OWNER, no permitía el acceso al resto de usuarios a obtener sus propiedades (razón por la que saltaba el error en el método getMembers).

Para reproducir el error, prueba a añadir ese permiso a un usuario de otro grupo. Esto lo podemos hacer a través de javascript:

usuario.setPermission("All", "ROLE_OWNER");

El efecto fue el esperado, al lanzar el script con este nuevo grupo saltó el error. Para corregirlo procedí a eliminar el permiso:

usuario.removePermission("All", "ROLE_OWNER");

Sin embargo, cuando volví a lanzar el script, seguía dando el error. Por algún motivo se había perdido un permiso que heredan todos los usuarios:

"Read", "GROUP_EVERYONE"

aunque aparentemente la herencia la tenía activada. Le otorgué este permiso:

usuario.setPermission("Read", "GROUP_EVERYONE");

y al lanzar nuevamente el script, ya corría adecuadamente.

Por algún motivo, al eliminar el permiso de ROLE_OWNER a través de javascript, la herencia de GROUP_EVERYONE se pierde. ¿Se trata de algún bug o estoy utilizando de forma incorrecta los permisos?.

De todos modos, está claro que para lanzar la mayoría de los scripts de administración, lo mejor es tener permisos de administrador, por lo que la solución que mejor se adapta a esto (y evitar este tipo de problemas) es configurar la autenticación con user, pero lanzar los scripts con la directiva runas:

<authentication runas="admin">user</authentication>
 
 Para poder utilizar esta directiva, los webscripts deben guardarse en el Java Class path.

Comentarios

Entradas populares de este blog

Conexión a bbdd oracle desde python

Para poder acceder a una bbdd oracle desde python tan sólo necesitaremos tener instalado: - cliente oracle (lo puedes obtener de la página de oracle y registrándote en la misma) - extensión cx_Oracle (lo puedes descargar desde la página http://cx-oracle.sourceforge.net/) La forma de utilizarlo lo podemos ver en el siguiente ejemplo: Con este script se pretende actualizar el campo de una tabla pasándole tres argumentos, dos para filtrar el dato y uno que será el nuevo valor. También hacemos uso de optparse para pasear los argumentos. #!/usr/bin/python # -*- coding: iso-8859-15 -*- import cx_Oracle, sys, os, datetime from optparse import OptionParser conn_str='usuario/pass@host:port/bbdd' log = '/ruta/para/log/script.log' #Fucion para escribir log def log (texto):         now = datetime.datetime.now()         f = open(log_propio, 'a')         f.write(str (now.ctime()) + ' -> ' + texto + '\n')         f.close() #Se parsea

Curso Django Segunda Parte

Continuamos con la segunda parte del mini curso de django. Respecto a la primera parte, he añadido una par de cosas: - La instalación de un paquete más: python-pygraphviz - Y la aplicación de un parche para django-smart-selects: https://github.com/GrAndSE/django-smart-selects/commit/7e2a8d572b3615cc39a3c9f9d60e1b60de06f46f Pues bien, ya tenemos creado un proyecto llamado misitio. Ahora es el momento de crear nuestra aplicación, la cual llamaremos inventario. Para crear un aplicación, simplemente hacemos: cd /opt/djcode/misitio python manage.py startapp inventario Tras la ejecución de este comando (que no devuelve nada por pantalla), tendremos un nuevo directorio bajo el proyecto misitio: ls -l inventario/ -rw-r--r-- 1 root root   0 mar 11 12:27 __init__.py -rw-r--r-- 1 root root  57 mar 11 12:27 models.py -rw-r--r-- 1 root root 383 mar 11 12:27 tests.py -rw-r--r-- 1 root root  26 mar 11 12:27 views.py De los ficheros que nos podemos encontrar, tenemos:

Configurar Nano Wifi TL-WN725N en Raspberry pi

Hace poco me regalaron una raspberry pi, y junto con ella, un dongle wifi usb TP-LINK, modelo TL-WN725N. En principio se supone que no debe haber problemas de compatibilidad entre este dongle wifi y nuestra raspberry, pero si la versión de nuestro dongle wifi es la 2 (en la caja viene como Ver:2.0) la cosa cambia. En mi caso tenía instada la última versión de raspbian, la cual traía una versión de kernel superior a la 3.10.18. Esta versión de kernel es la que funciona con nuestra modelo de dongle wifi (al menos según he podido averiguar). De modo que para poder reconocer el dongle wifi, tendremos que bajar a esta versión del kernel: sudo rpi-update 8fd111f77895450323abc5b34efde19548ffc480 Tras reiniciar, tendremos el siguiente kernel: Linux raspberrypi 3.10.18+ #587 Ahora sólo nos queda instalar el driver: wget https://dl.dropboxusercontent.com/u/80256631/8188eu-20131110.tar.gz tar -zxvf 8188eu-20131110.tar.gz                                          cat README