Desmitificando las sesiones en Flex

El tema de las sesiones es una pregunta que cada cierto tiempo suele salir a la luz debido a que practicamente todos venimos del mundo de las aplicaciones web tradicionales. Debido a una pregunta en la lista de correo de MIF me he animado a escribir este artículo.

Ante todo, la pregunta que deberíamos formularnos es: ¿Son necesarias las sesiones en una aplicación RIA con Flex?.

La respuesta es NO. En clientes RIA creados con Flex, al igual que con las aplicaciones cliente-servidor tradicionales, no es necesario el mantener una sesión con el servidor en la forma tradicional que conocemos y que practicabamos con las viejas aplicaciones HTML. De hecho si habeis creado alguna vez una aplicación cliente-servidor…¿habeis necesitado alguna vez el concepto de sesión?. Lo normal es que la respuesta sea negativa, ya que este es un “hack” creado por las necesidades de los clientes ligeros y que ha terminado siendo un vicio heredado que intentamos usar en las nuevas aplicaciones RIA.

En mi experiencia creando aplicaciones RIA (con Flex o Flash) no he encontrado hasta ahora ningún caso de uso en el que necesitase mantener una sesión con el servidor ya que dispongo de un cliente con estado. Es decir el cliente “no pierde la memoria” entre petición y petición al servidor manteniendo dicha información siempre accesible. Por tanto, el uso de sesiones en aplicaciones RIA creadas con Flex es algo que deberiamos ir dejando de lado ya que son innecesarias. En su momento, en la epoca de las aplicaciones basadas en clientes ligeros, era necesario este concepto ya que las aplicaciones no mantenian el estado y cada petición significaba el enviar el identificador de sesión para que el servidor supiese que cliente estaba realizando la petición. De esta forma se podía recoger la información guardada en el servidor para usarla en el procesamiento de la petición en curso. Ahora, la información sensible a la sesión, se guarda en el cliente, por tanto se mantiene activa y viva mientras dura la sesión de ese cliente o, lo que es lo mismo, mientras el cliente Flex permanece en memoria. De forma colateral esto supone un ahorro de memoría (aunque muy pequeño) en el lado del servidor.

En cuanto a temas de seguridad, conviene tener en cuenta que Flex permite añadir las credenciales de un usuario al invocar servicios en el servidor (ver “Passing credentials from client-side components” y el uso de los métodos setCredentials y setRemoteCredentials) securizando aquellos servicios que queramos que solo sean accesibles por determinados usuarios. Además podemos delegar la seguridad al servidor de aplicaciones de forma que sea este el que gestione la autenticación de los usuarios (normalmente mediante un sistema como JAAS, o un API similar)

Además, podemos usar Local Shared Objects (LSOs) para persistir información entre sesiones (si por ejemplo, quereis que el cliente recuerde el último usuario logado y lo escriba al inicio de la sesión en la ventana de login para facilitar al usuario el acceso en sucesivas sesiones).

Aún asi, y para aquellos nostalgicos apegados a antiguas prácticas, hay soluciones para acceder a una sesión HTTP. En OpenAMF teneis la clase RequestContext (org.openamf.RequestContext). En FDS2 buscad por “Working with session data” para saber como se accede a los datos de sesión. Para otros paquetes supongo que también existirá algo implementado por el estilo. El motivo real para que este tipo de soluciones existan es por un lado mantener la flexibilidad dando más posibilidades y a la vez evitar que un recién llegado a esta tecnología la menosprecie por desconocimiento, pero lo recomendado es usar el cliente para guardar la información sensible a la sesión.

Comparte:

Acerca de esta entrada

Usted está leyendo “Desmitificando las sesiones en Flex,” una entrada de MadeInFlex

Autor: Carlos Rovira: Carlos es un Consultor especializado en Rich Internet Applications y en la Plataforma Flash. Actualmente trabaja en Codeoscopic como Director Tecnológico.

URL del Autor:: http://www.carlosrovira.com

Ver: otras entradas del autor

Publicada:: 01.11.06 / 9pm

Categorías:: Artículos

Entradas relacionadas:: Transparencias de las presentaciones
ÃƒÅ¡ltimas plazas para mif onSite I
Próxima parada: MAX 2007 Barcelona
Directo desde MAX 2006

Número de visitas:: 3796

Próximo encuentro...

ablesa 01.11.06 / 11pm

Estoy de acuerdo contigo, Carlos, pero me gustaria apuntar que si que hay un caso en el que es interesante y muy importante acceder a las session web desde el cliente Flex. El escenario sería aquel en la que tenemos una aplicacion web tradicional, en la que hacemos login(y guardamos en la session web el userVO por ejemplo) y una vez hecho el login redireccionamos a la aplicacion Flex. En ese punto puede ser interesante acceder a la session del usuario para certificar que realmente se ha logueado, sin necesidad de hacer login desde el cliente Flex, claro. Un ejemplo claro del escenario al que me refiero es Goowy.
Por lo demás pienso que tienes razón en indicar que el hecho de guardar la session en el servidor, viene claramente de un tipo de aplicaciones web en las que el cliente no retenía el estado, caso en que las aplicaciones Flex no tiene sentido.
un saludo para todos,
ablesa.

Hector 02.11.06 / 12am

Pienso igual de ablesa, en una aplicación que tiene acceso a datos confidenciales, es importante certificar que la petición del cliente es realizada por un usuario con los permisos necesarios, incluso a lo largo de su sesión.

Carlos Rovira 02.11.06 / 1am

Vaya, algo ha pasado en la entrada que escribi. Al revisar la entrada, metí un parrafo sobre temas de seguridad…y por alguna razón no se guardó en la entrada (quizá con las prisas olvidé pulsar el botón de guardar). Perdonad la confusión.

He vuelto a meterlo una mención al tema de seguridad para dejar claro que disponemos de una buena granularidad con respecto a la autenticación de usuarios por servicio.

Si bien, puede ser necesario usar sesiones cuando estemos integrando con otras aplicaciones web tradicionales, las posibilidades de usar los mecanismos de autenticación que ofrezca el servidor Java en unión de las técnicas que ofrece Flex (setCredentials, etc…) nos deberían bastar, si la aplicación es una RIA pura, para tener seguridad en el acceso por servicio y usuario.

danisan 02.11.06 / 1pm

Puestos a aportar más escenarios, otro caso en el que he utilizado sesiones con clientes flash es para implementar estadísticas y usuarios únicos, por si refrescaban la página que no contabilizara como nuevo visitante, etc.

Hector 03.11.06 / 3am

Carlos, aparte de JAAS, serias tan amable de comentar (si conoces) otros mecanismos de autentificación del lado del servidor que sean libres talves para trabajar con php o ruby.

Gracias

Carlos Rovira 03.11.06 / 1pm

Hola Hector, La verdad es que cuando he tenido que hacer temas de seguridad han sido siempre con Java, por tanto, no se cuales son las soluciones existentes en PHP o en Ruby . Sorry. ¿algún experto en el tema que nos pueda ilustrar? .

Hector 09.11.06 / 5am

creo que nadie, pero me pondré a investigar, lo que encuentre aviso
Saludos

Mauro Luna 13.11.06 / 5am

Carlos, buen artículo y muy interesante.

Solo tengo una duda, sobre lo que comentas de no requerir del manejo de sesión en una aplicación RIA, cómo aplicarías esto en una aplicación corriendo en ambiente de ‘balance de cargas’ de Web? puesto si tienes una granja de servidores que atienden la peticiones de un o de varios usuarios, cómo puedes saber qué es lo que esta procesando?

Mi experiencia ha estado hasta este momento en ColdFusion, ahora Flex-CF.

Saludos.

Carlos Rovira 13.11.06 / 12pm

Hola Mauro,

En principio cuando hablamos de aplicaciones críticas donde requerimos alta disponibilidad y balanceo de carga lo normal es que usemos un software que esté preparado para ello. Lo mejor sin duda es Flex Data Services 2 (versión comercial) que permite clustering y balanceo de carga tanto por software como por hardware. FDS2 al fin y al cabo es una aplicación J2EE que puede ser escalada gracias a su naturaleza java y a su integración con los servidores de aplicaciones donde se instala que facilitan este tipo de cosas.

Te recomiendo que le heches un vistazo al siguiente documento:

http://www.adobe.com/products/flex/whitepapers/pdfs/flex2wp_fdscapacityplanning.pdf

Dano 20.11.06 / 6am

[quote]¿Son necesarias las sesiones en una aplicación RIA con Flex?.

La respuesta es NO. En clientes RIA creados con Flex[/quote]

Muy buen artículo, pero me gustaría aclarar algo, las sesiones, para cuestiones de seguridad SIEMPRE son necesarias. Refiriendome en concreto a php, probablemente no es necesario invocarlas como tal, ya que podemos utilizar el setCredentials, ya sea usando AMFPHP y WebOrb.

Pero ambos para manejar tales credenciales si que usan Sesiones, es que un servidor ¿cómo comprobaría que una credencial enviada por Flex es válida? si no guarda una copia de la misma. Sería una gravísima vulnerabilidad.

Resumiendo, las sesiones no se usan para almacenar un carrito de compras, un nombre de usuario, preferencias, y demás necesidades de nuestra lógica de negocios. Pero para nuestra seguridad(credenciales) no las podemos olvidar.

Para aclarar un poco, les proporciono como maneja WebOrb las credenciales, tiene una clase llamada ThreadContext, que contiente este método:

[code] private function setCredentials($currentCallerCredentials)
{
$_SESSION["credentials"] = $currentCallerCredentials;
}[/code]

saludos

Carlos Rovira 20.11.06 / 8am

Dano, Muy buen comentario. Gracias por tus valiosas aclaraciomes .

Pero si es el cliente el que genera una nueva sesión y accede a servicios del servidor con las credenciales ¿Es realmente necesario que el server guarde una copia de esas credenciales?. Al fin y al cabo si se intenta hacer un acceso con credenciales no validadas el servidor va a rechazar dicho intento. Es decir…el mantener una copia de la sesión me parece redundante.

Como ya comento en el artículo ¿las antiguas aplicaciones cliente-servidor usaban sesiones? No. ese concepto fué creado por la naturaleza estática de HTML.

De todas formas, creo que puede ser muy beneficioso que los distintos paquetes para crear RIAs tengan ese tipo de soporte ya que da más versatilidad.

Nuevamente gracias por tu opinión .

isai 25.02.07 / 11pm

Hola te felicito por tu blog, gracias a ti he conseguido aclarar el tema de las sesiones.

Y sigue con tu blog que hasta ahorita los articulos que tienes publicados son muy útiles

Saludos
Centro Software Libre

Juan Manuel 20.05.08 / 8pm

Creo que sería interesante poder manejar datos de la sesión aunque no fuera teóricamente correcto, recordemos que se hacen muchas cosas de manera incorrecta y sin necesidad

Desmitificando las sesiones en Flex

Acerca de esta entrada

13 Comentarios

Su comentario

Próximo encuentro...

Entradas Recientes

Archivos Mensuales

Top Entradas

Mejores entradas del mes

Categorías