ExtJS y autorización de página (del lado del servidor)

Question

Estoy buscando información sobre cómo implementar páginas seguras usando ExtJS 4. Me refiero a páginas seguras que el usuario iniciará sesión en nuestro sitio web usando Siteminder (SSO) y entonces tendremos la identidad del usuario. Luego, determinaríamos qué funciones tendría el usuario al hacer una llamada de base de datos/LDAP y solo representar aquellas vistas/componentes a los que el usuario tiene acceso.

varias preguntas vienen a la mente:

1.) Por supuesto que sería de esperar que íbamos a hacer la comprobación de autorización antes de rendir las páginas en el lado del servidor, así que ¿cómo hacer esto antes de disparar Ext. onReady()? Necesito que el ExtJS espere la respuesta del servidor?

2.) ¿Cuál es la mejor manera de organizar los componentes de una página en los casos en que alguien podría ver un componente en particular y otra persona no?

3.) ¿Cómo envío la página resultante (es decir, las piezas a las que tiene acceso el usuario) al cliente?

TIA!

Answer 1

1. Utilice una tecnología del lado del servidor para preprocesar la autorización colocando el script de inicio de la aplicación JS en un JSP/GSP. Lo que hace esto es forzar a los componentes del lado del servidor a iniciarse primero y luego renderizar el HTML/JS/CSS al cliente. Para la aplicación RIA completa use index.gsp (o jsp) y su URL se mantendrá como "dominio/contexto".

2. Puede consultar los privilegios de acceso al contenido mediante solicitud ajax al servidor o, alternativamente, puede establecer las variables JS a través de la tecnología JSP que se procesa primero antes de devolver el resto de la respuesta del cliente.

< g: javascript>

//global env var definition 
    var env = "${System.getProperty(Environment.KEY)}"; 

< /g:javascript> 

Ambos de estos no son 100% seguro como el código del lado del cliente puede ser alterado. La aplicación de seguridad real debe manejarse en el servidor cuando los datos se envían para su procesamiento.

'3. La manera más fácil sería ocultar/mostrar vistas, etc., según 2. arriba. También hay algo de experimentación con la modularización de la aplicación MVC del lado del cliente mediante controladores de inicialización perezosos (manualmente) que pueden o no ser necesarios.

Espero que esto ayude.

DB :)

Answer 2

1. la salida Role-based access control. Uso el RBAC basado en bases de datos de Yii, y tengo un script php que devuelve las reglas rbac en formato json cuando se inicia ext

2. en el cliente, la mejor opción es simplemente ocultar o deshabilitar la funcionalidad que no está permitida.

3. en el servidor, debe lanzar un 403 http error si el usuario no puede realizar una función. maneje las excepciones ajax en ext y verifique 403s.

Answer 3

Actualmente estoy experimentando con la siguiente solución. Aunque solo funcionará para aplicaciones con un conjunto bastante simple de usuarios, podría ser de alguna ayuda para usted.

Para empezar, la autenticación de usuario se realiza sin extjs, utilizando una página HTML/CSS simple. Una vez que el usuario inicia sesión, sus detalles (identificación de usuario, función) se guardan en la sesión de PHP. Y luego la página redirige a una de las dos aplicaciones extjs.

Una aplicación para usuarios normales (los llamaré clientes), estas son personas que en el lado del cliente JS no incluye ninguna funcionalidad de administración. La otra aplicación es para administradores.

Ambas aplicaciones tienen sus clases heredadas de las clases base. Así que tenemos, por ejemplo, base.mainMenu de la cual heredan tanto admin.mainMenu como clients.mainMenu. La única diferencia en el script app.js son los controladores cargados, y por módulo de carga dinámica extJS 4, solo se cargan las vistas relacionadas (es decir, se ven en el lado del cliente). En mi caso, todas las páginas se cargan dinámicamente de todos modos, por lo que mis usuarios solo pueden cargar páginas dinámicamente en su menú principal.

La aplicación de administración bloquea ciertas características utilizando una variable JS global que incluye el rol del usuario. Entonces, por ejemplo, ocultar una tecla 'editar' de moderadores (un grupo de administración con menos derechos) se realiza una vez que se carga la vista (en la práctica, esto se hace no cargando un complemento que permite editar la vista).

Para concluir, cualquier llamada al servidor comprueba si el usuario de la sesión tiene derechos para la operación solicitada, por lo que independientemente de las secuencias de comandos del lado del cliente, la operación del servidor solo puede ser realizada por personas con los derechos adecuados.

En resumen, usted tiene 3 estrategias diferentes que se pueden mezclar y combinar:

• Cargando diferentes aplicaciones para diferentes usuarios. Si sus clases son inherentes a las clases base, esto es más fácil que mantener 2 o más aplicaciones completamente diferentes.
• Usando una variable JS global para deshabilitar/habilitar ciertas funciones para ciertos usuarios. Esto solo es bueno si no tiene un problema con las funciones de carga del lado del cliente que luego están deshabilitadas (pero que los depuradores aún ven).
• Sin importar nada, todas las llamadas del lado del servidor se comparan con la variable de sesión.

Answer 4

Si está trabajando con un fondo Java y se siente cómodo con Spring, escribí un enfoque utilizando Spring Security here. Esto le permitirá conectar cualquier mecanismo de autenticación que desee. La diferencia principal es que en lugar de usar un index.html para arrancar la aplicación, tengo un JSP para que el filtro del servlet de primavera se active para la autenticación. La aplicación Ext JS bloquea hasta que el usuario se autentique y se proporcionen los roles/permisos del usuario.