Hola, vuelvo a opinar que tienes una confusión en cómo deseas llevar a cabo tu proceso. O tal vez yo entiendo mal tu aplicación. Ejemplo: si yo soy un usuario de tu App y he olvidado mi password para ingresar, puedo solicitar un reset mediante un link en tu aplicación en la vista de sign-in. Tu App me enviará un correo, el cual tendrá un vínculo a una página de reset, la cual debe mostrarse sólo a quien incluya en la URL como parámetro un token válido, y algún otro parámetro que escojas (normalmente el correo del usuario). Por ende el token ha de ir en la URL y no en la cabecera (header)

Por lo tanto, tu App debe leer el token desde la URL y no esperarlo en la cabecera. Así mostrará la vista de reset sólo si el token es válido. No se si eso es lo que necesitas hacer. Si no, por favor explicame qué me pierdo de tu App. Tal vez soy yo el que no lo entiendo.

Así, tus middlewares isNotLoggedIn y ensureToken no tienen sentido en esa ruta, ya que yo no logro hacer login (porque olvidé el password) y por lo tanto no tendré un token de autorización para mi sesión de usuario. Tal vez si quitas esos middleware de tu ruta, lograrás lo que intentas. Saludos

todo bien, mando el token por la url, y lo recibo como parametro /:token Si yo mando desde postman un get con un token como parametro y en los headers content-type y auth , me devuelve la vista, pero si accedo a la vista desde mi gmail, o lo que sea me manda un forbidden, aún cuando le mando el token. Ese es el problema que tengo.

@MauricioContreras por ende yo supongo o imagino que debe haber una forma de mandar content-type y auth dentro de la url que estoy creando dentro de el transporter

Porque hay algo en tus middleware isNotLoggedIn y ensureToken que deben estar interfiriendo. Quita esos middleware de tu ruta y realiza la prueba.

si quito el ensureToken que sentido tiene mandar el token? @MauricioContreras

Qué hace ensuretoken?

Si mal no comprendo, ensureToken verifica un token de autorización, que no es el mismo que envías por correo para reset de password.

así es

ya le quite el isNotLoggedIn y me manda forbidden

El token de autorización se genera al momento de hacer login. Si el usuario y la clave coinciden, mi aplicación genera un token de autorización y lo envía al cliente. Es responsabilidad del cliente o de la aplicación del cliente enviar luego dicho token en cada peticion a mi app para poder acceder a rutas protegidas.

si

este es mi ensure

puro y simple

El token para cambiar la clave es diferente. Y para acceder a la ruta de cambio de clave sólo debo solicitar un token válido por URL, se supone que dicho token es enviado únicamente al correo registrado del cliente, y va como un link que lo incluye.

me da sttatus 200

La ruta es pública y no debería estar protegida

mmm

Lo se, estas estableciendo una cabecera de autorización. Pero esa ruta no debería pedir autorización

pero entonces para que token en primer lugar?

El token garantiza que el usuario es quien dice ser (se supone que sólo el usuario tiene acceso a su propio correo) además dicho token de reset debe tener un tiempo de vigencia no superior a 12 horas o menos según tu dispongas.

Recuerda que eres tú quien genera el token y lo envías al correo del usuario. Es el usuario quien accede a su correo y hace clic en el enlace. El enlace por lo tanto debe incluir ese token que sirve únicamente durante 12 horas para acceder a la ruta de cambio de password

ok, pues le quitarè el ensure

y ya alv

gracias por tu tiempo mauricio

eres de mis favs

creeme aportas mucho a mi desarrollo profesional con tu tiempo

Te funcionó?

si claro sin el ensure si, ya solo queda probar desde en vps pero todo bien gracias