¿Cómo respondo a un servidor de correo no deseado que invalida mis tokens? [duplicar]

2

Nuestra aplicación web envía un token generado de un solo uso, en forma de una URL, a los clientes que olvidan sus contraseñas. Esto funciona excepto en el caso de que el cliente esté sentado detrás de otro servidor que escanea su correo electrónico en busca de URLS y realiza un GET en la URL. Supongo que el servidor está buscando una carga útil maliciosa.

El cliente abre el correo electrónico y hace clic en el enlace, pero obviamente no pasa nada porque el token no es válido en ese momento.

Puedo pensar en algunas formas de manejar esto:

• En lugar de caducar de inmediato, permita que el token sea válido durante un período de tiempo determinado. Desventaja: Esto elude todo el punto de un token de uso único ya que el token se puede usar varias veces. Además, puede que no resuelva el problema si el usuario decide abrir su correo electrónico ANTERIOR a la fecha de caducidad.

• Hacer que el token sea bueno para dos usos. Desventaja: similar a la anterior. ¿Qué pasa si el verificador de spam "comprueba" la URL de nuevo ... Suspiro.

De todos modos, estoy buscando algo de sabiduría aquí sobre cómo manejar esto. Si hay mejores ideas que las que he propuesto, me encantaría escucharlas.

EDITAR: He publicado esto en programmer.stackexchange . Vaya allí para un poco más de discusión, pero la respuesta que seleccioné a continuación es básicamente la misma respuesta.

    
pregunta Avery 04.10.2014 - 05:53
fuente

2 respuestas

6

El problema con el que te encuentras es que se supone que GET es tanto "seguro" como "idempotente": es decir, llamarlo no debe hacer ningún cambio en el servidor y hacerlo muchas veces Debería tener el mismo efecto que llamarlo una vez. Desde el punto de vista de los estándares, debería utilizar un POST para usar el token.

Obviamente, no puedes hacerlo desde un correo electrónico. Una opción es que el enlace en el correo electrónico no haga nada en realidad, es solo un enlace a una página que hace el trabajo real. Hacer clic en un botón o, de lo contrario, provocar un POST desde esa página sería la única acción que expira el token y hace lo que sea necesario para el manejo de la contraseña olvidada.

    
respondido por el Mark 04.10.2014 - 06:35
fuente
0

Puede intentar enviar no solo el token en el correo electrónico, sino también una cookie asociada con el token al navegador. En la verificación, tanto el token como la cookie deben presentarse, por lo tanto, el token solo se puede utilizar con éxito con el navegador que solicitó el restablecimiento de la contraseña.

    
respondido por el Steffen Ullrich 05.10.2014 - 10:40
fuente

Lea otras preguntas en las etiquetas