Hola,
Cita:
|
Empezado por Román
(...) actualmente manejas en loturak, via http, una autentificación y tal y es lo mismo de insegura que en el caso que te ocupa ahora. Si vía http no te quita el sueño, ¿por qué te lo quita ahora?
|
Bueno. Efectivamente, porque se me ocurrió así desde un principio. Es decir, desde el momento en que era necesaria la autentificación del usuario pensé que podría enviarse el MD5 de la contraseña. Es cierto que Mario a puesto en evidencia que los datos del enlace siguen enviándose en claro, y, esto en los enlaces públicos importa menos, pero, en los privados... en fin.
No sé. Supongo que he ido a salvar la contraseña por todos los medios posibles mientras que el resto de datos he dado por supuesto que viajarían en claro... sin más. Lo que significa le hecho de que lo decidiera así es que ahora pienso que podría hacer lo mismo con la contraseña en la autentificación en Loturak, no en el API... sino en la propia página Web. Se me ocurre que podría codificar la contraseña igualmente con MD5 valiéndome de JavaScript.
La seguridad es algo que habría que tener en cuenta... a lo menos hasta donde pudiera llegar uno. Mismamente al liarme con todo esto del API he solucionado (hasta donde llego) un par de problemas de seguridad en sendas partes de Loturak: era posible hasta anteayer para un usuario registrado editar así como borrar enlaces de otros usuarios. No sencillamente, es decir, requería comerse un poco la cabeza, pero, no demasiado. Y sin embargo, pensando en todo esto... los datos siguen viajando en claro...
Cita:
|
Empezado por Román
Por otro lado, no entiendo eso de mandar la contraseña cifrada.
|
Bueno. Ya digo que es una idea mía... así que puede ser perfectamente inútil o innecesaria... de hecho en
WordPress, sin ir más lejos, no se cifra la contraseña del usuario cuando esta se utiliza el API XML-RPC conque cuenta este gestor de contenidos. A lo menos eso he creído entender luego de revisar el código fuente relacionado. Ya digo. Lo pensé así Román... centrándome (acaso un tanto irracionalmente, puesto que dejo los datos del enlace en claro), digo, queriendo proteger la contraseña del usuario.
Cita:
|
Empezado por Román
Hasta donde entiendo, en el caso de la autenticación de loturak, la contraseña cifrada te sirve para poder mantener al usuario en sesión (no digo logueado porque suena horrible) sin necesidad de guardar la contraseña real en una cookie, pero en algún momento debe hacerse la autenticación. ¿Cómo se llevaría esto a cabo con la API?
|
Efectivamente, usando un par de Cookies conseguimos que la autentificación del usuario "persista" en el tiempo. Lo que se guarda en la Cookie... no te lo vas a creer... es el MD5 (no recuerdo ahora mismo si doble) del MD5 (este seguro doble) de las contraseñas de los usuarios. Me parece que añado algo más en la clave que guardo en la Cookie...
Ahora bien, en todo caso, no sé si te aclarará el asunto un poco si te digo que las contraseñas de los usuarios no se guardan en claro en la base de datos, sino que se guarda el "doble MD5" de las contraseñas. Los métodos del API que lo necesiten ya recogen el doble MD5 de una contraseña de usuario, así que la autentificación se lleva a cabo con el login de usuario y con la contraseña tal cual llega, pues es justo lo que se necesita.
Cita:
|
Empezado por Román
Otra cosa, ¿me podría alguien explicar qué es una API-KEY?
|
Pues debe ser algo como una "llave" que permita a determinado programador/desarrollador acceder a un determinado API. No tienes la "llave"; no puedes acceder al API.
Google hace uso de esto en sus APIs... generalmente, al menos, asigna al que lo solicita una clave (creo que única). En el caso de Google además, al menos para ciertas APIs, asigna a cada clave un número limitado de "consultas a la API"... que es algo que no sé muy bien cómo va exactamente, pero, en definitiva, no puedes "buscar en Google" desde tu aplicación más de 1.000 veces al día o algo así... ciertamente yo también estoy verdísimo en todo esto, como en casi todo, cada vez que lo pienso más.
