Vamos a ofrecer contenido a un sistema de gestión de contenido que lo incrusta a través de un iframe (yuck). Algunas páginas que servimos deben estar autenticadas antes, solo un usuario válido debe poder verlas.
La compañía que implementó previamente lo que vamos a hacer lo hizo a través de las solicitudes. Por supuesto, ya que no hubo gestión de sesión. El uso de iframe s hizo imposible el uso de cookies, etc. Esto no es una autenticación real, pero eso es lo que hicieron ...
http://example.com/get.php?ID=1234&[email protected]
Créalo o no: uno podría obtener fácilmente el contenido de otro usuario intercambiando ID o correo electrónico. Ahora queremos (o tenemos) cambiar eso. El problema es que no tenemos acceso a los datos del cliente . No sabemos la dirección de correo electrónico ni las ID de usuario del CMS.
El plan inicial que se había desarrollado era enviarnos un hash salado con correo electrónico e identificación, y alguien pensó que era posible extraer el correo electrónico y la identificación del hash nuevamente si conocíamos la sal. Bueno, resulta que no sabían cómo funcionan los hashes ... así que me toca proponer algo nuevo.
Aquí está el primer escenario que pensé:
Enestecaso,solorecibimosunalistadehashválidosdelCMSyverificamossielhashquenosenvióelusuarioesválido.ElproblemaaquíesquenecesitamosunalistadehashesyelCMSdebeenviarlosanuestroservidordealgunamanera.¿Hayalgúnotroproblemaquemeestéperdiendo?¿Quépasaconlosusuariosqueintentantodosloshashesposibles?
Segundoescenario:
Recibimos el hash del usuario y lo enviamos de vuelta al CMS. El CMS verifica que este hash realmente existe y nos dice si podemos servir el contenido. Aquí, el problema es que se deben realizar solicitudes adicionales (¿rendimiento?).
Tercer escenario, que creo que debería encajar en nuestro caso:
El usuario nos envía su correo electrónico, ID y el hash que el CMS generó para ellos. Compartimos una clave secreta (la sal) con el CMS, y tratamos de reconstruir el hash del correo electrónico y la identificación. Si coincide, el usuario debe haber sido autenticado en el CMS antes, para que podamos servir el contenido.
El problema aquí es que enviamos el correo electrónico a través de la URL. Ahora, la implementación anterior (insegura) también hizo esto, pero no sé cuánta es la cuestión de la privacidad.
Conclusión: ¿hay algo que haya pasado por alto en los ejemplos anteriores? ¿El último escenario se ajustaría a nuestro caso, o hay otro método fácil para autenticar a un usuario cuando no tiene acceso a los datos privados de su lado del esquema?
