[Python-es] webapp2 y REST - Guardar el estado del cliente con cookies.

[Chema Cortes]

El día 8 de octubre de 2012 18:19, Txema Vicente <txema en nabla.net> escribió:

> Estoy intentando hacerme un toolkit con webapp2 en GAE, que me facilite
> producir aplicaciones Dojo desde python.
>
> La idea es que el cliente entra a la pagina principal (State: Ninguno), se
> le envia HTML y el Javascript básico (State: Iniciando), y despues de eso se
> crea el interfaz de usuario, y todas las peticiones a partir de aqui
> (Estado: Listo) son AJAX ó "Dojo-require" que le dan más javascript al
> cliente. No se responde nada si no viene de un cliente ya "Listo", y si la
> peticion requiere un State distinto, se le pasan las tareas al cliente que
> lo lleven a ese estado.
>
> Como intento que sea RESTfull, si lo entiendo bien no debo usar sesiones,
> sino que el propio cliente siempre debe comunicar su Estado en cada
> petición.
>
> Asi que lo hago con cookies,  el problema es que si abre otra pestaña, las
> cookies siguen ahi pero el Estado no es correcto.
>
> De momento lo he arreglado así:
>
> - Al iniciar, javascript crea una cookie "state_hash" con un número único
> XXX que le ha pasado python.
> - Cada vez que hace una petición, el cliente javascript crea una cookie
> "state_check"=XXX
> - Cada vez que recibe una petición, el servidor python comprueba que
> state_hash==state_check:
>         - Si: le elimina la cookie "state_check" y le responde lo que pida.
>         - No: le responde 404 No cuela.
>
> Pero digo yo que para esto habra soluciones ya pensadas, no?
> Otra forma de hacerlo sin cookies?
> Agradezco enlaces o ideas sobre estos temas (REST, generar JS desde python).

Aunque no conozco mucho estos sistemas, yo usaría exclusivamente las
cookies para guardar estados "globales" tales como autenticaciones o
parametrizaciones de la aplicación con los que construir más
fácilmente la URL del servicio REST.

Para lo que necesitas, veo más práctico crear código javascript "al
vuelo" que incluya algún token con el que construir la URL según un
formato aceptado por el servidor. Este token podría estar firmado por
una clave pública para mayor seguridad, e incluir algún tipo de marca
temporal para compararla con el reloj del cliente cuando sea necesario
algún tipo de sincronismo o de timeout.




-- 
Hyperreals *R: http://ch3m4.org/blog
Quarks, bits y otras criaturas infinitesimales