java - invocar - Asegurar una API REST
jira rest api authentication (4)
Estoy en el medio de desarrollar una aplicación web de redes sociales PHP que será respaldada por varios servicios web, cada uno operando una API REST. Los servicios web probablemente se implementarán en Java con la capa de datos de MySQL, pero el objetivo principal de lo que estoy tratando de hacer es facilitar la implementación de módulos en diferentes idiomas / tiendas de datos dependiendo de lo que sea apropiado.
Entonces, por ejemplo, cuando el usuario inicia sesión en la aplicación a través de un formulario de inicio de sesión, el código PHP se conecta a un servicio web y envía el nombre de usuario y la contraseña para verificar si deben autenticarse. Normalmente, en este punto comenzaría una sesión y la almacenaría en una tienda de datos de sesión.
Otro ejemplo podría ser si un usuario envía un mensaje privado a otro usuario. El mensaje se ENVIARÍA al servicio web de mensajería privada que se encargaría de todo el almacenamiento. Del mismo modo, el servicio web podría ser contactado para recuperar mensajes para un usuario.
Aunque entiendo cómo implementar el servicio web REST en Java y realizar la conexión en PHP, no estoy seguro de cómo proteger los datos que se pasan y me aseguro de que sean los datos de los usuarios que se devuelvan. Si, por ejemplo, quiero obtener todos los usuarios Como mensajes privados, ¿cómo sabe el servicio web para devolver esos usuarios? Podría pasar ese identificador de usuario como parte de la url GET, pero seguramente cualquier usuario anterior podría descubrir la URL GET y usarla para buscar mensajes de otras personas. Pensé que quizás podría pasar el identificador de sesión y la dirección IP, lo que me permitiría verificar el almacén de datos de la sesión y asegurarme de que es el usuario correcto.
Para asegurar la información que es importante, como el nombre de usuario / contraseña, pensé que simplemente pasaría el SSL.
Espero que esto explique mi problema mejor.
Gracias
Creo que requerir OAuth es una buena opción. Sus usuarios finales deben apreciar que otros sitios web no necesitan pedir nombres de usuario y contraseñas para acceder a sus datos. En cuanto a SSL, vale la pena hacerlo si puedes. Deberá ver si la compensación de rendimiento es aceptable.
Estas son básicamente 2 preguntas.
Cuando la privacidad es una preocupación, elegiría la opción más segura: servir datos a través de SSL (a través de HTTPS).
En lo que respecta a la autenticación, hay varias posibilidades. Básico sobre SSL es uno de ellos, pero un formulario de inicio de sesión simple con una cookie puede ser otro. (Autenticación de formularios de ASP.Net, por ejemplo). Todo esto depende de cómo quiera implementar su mecanismo de autenticación.
Tenga en cuenta que su API debe imitar el protocolo HTTP.
Http es apátrida, y al agregar cualquier sesión más o menos, estás tratando de simular un método "Alwaysconnected".
Con un LoginForm, es como si tuviera que enviar dos solicitudes para cada llamada;)
Eche un vistazo a la autenticación HTTP Digest. La mayoría de los clientes deberían soportarlo, y significa que los detalles de autenticación se pueden pasar de forma segura con cada solicitud como parte de los encabezados sin interferir con la carga de la solicitud en sí.