Implementación de nuestro Sign-up

Clase 21 de 39 • Curso de Autenticación con Passport.js 2019

Helmer Barcos

student•

Para quienes tengan la version 16.1.7 de joi en adelante, deberian hacer un ajuste a la función validate en el validationHandler quedando asi:

function validate(data, schema) {
  const joiSchema = joi.object(schema)
  const { error } = joiSchema.validate(data)
  return error
}

David Behar

student•

Muchas gracias, me salvaste

Jorge Velasquez

student•

Excelente, me salvaste la vida, ya eran dos dias buscando una solucion 👏

Luis Lira

student•

No sé si más delante se verá la parte de que no se pueda hacer sign-up usando el mismo correo, pero yo así lo hice y lo comparto por si a alguien le interesa:

En UsersServices.js primero hice otro método encargado de verificar la existencia

async verifyUserExists({ email }) {
    const [user] = await this.mongoDB.getAll(this.collection, { email })
    return user
}

Y después en el post de sign-up lo llamo, si el objeto que le regresa el service y si el usuario ya está registrado le manda el mensaje de que ya existe y si no, lo crea. (lo mando con send porque no supe que statusCode se le pone 😅 ¿se le pone un 200?)

try {

    const userExists = await usersService.verifyUserExists(user)

    if(userExists) {
        res.send({
            message: 'user already exists'
        })
        return
    }

    const creadtedUserId = await usersService.createUser({ user })
    res.status(201).json({
        data: creadtedUserId,
        message: 'user created'
    })
} catch (err) {
    next(err)
}

Wilmar Yoan Malaver Malaver

student•

Genial Gracias.

Juan Carlos Del Rio Enciso

student•

Excelente aporte!!!

Rubén Esparza

student•

Cómo dato curioso la autenticación Basic no es muy segura, si no se utiliza bajo HTTPS, debido a que las credenciales van solamente encodeadas en el encabezado de Authorization y todo esto viajaría cómo texto plano si se utiliza bajo HTTP, al no tener una capa segura de transporte (SSL)

Authorization: Basic cm9vdEB1bmRlZmluZWQuc2g6cm9vdA==
Content-Type: application/json
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: 8a636c2e-b6bd-4b28-848e-086150b717fa
Host: localhost:3000
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 91

Si nosotros aplicamos un decode a valor cm9vdEB1bmRlZmluZWQuc2g6cm9vdA== con una herramienta cómo Base64URL Decode obtendremos las credenciales del usuario en el formato username:password, lo cual nos arroja las credenciales sin mayor complicación root@undefined.sh:root

Luis Velásquez

student•

Nada es seguro bajo HTTP. No solo te pueden robar datos que ingreses, sino que te pueden modificar el contenido del sitio sin que te des cuenta (con un ataque MITM).

Marco Antonio Macedo Preciado

student•

No termino de entender la utilidad de las apiKeys, ¿Entonces el cliente tiene que tener almacenado el apiKey y enviarlo cuando hace un request de autenticación? ¿Darle eso al cliente no es muy inseguro?

Alexis Alberto Texis Auza

student•

Hola marco,la finalidad de los apikeys es definir los permisos que tendrán los clientes,que este caso es el del ssr del frontend,pues es este quien tendra los scopes públicos por decirlo asi, y podra solo ejecutar tareas que tiene permitidas,ademas de que tendrá que guardarlo como variable de entorno para no tenerlo en plano.

Irungaray Agustin

student•

A alguien mas se le cae el server cuando hace el request con un usuario equivocado?

(node:13368) UnhandledPromiseRejectionWarning: TypeError: Cannot destructure property '_id' of 'user' as it is undefined.

Fernando Quinteros Gutierrez

student•

Lo solucione poniendo un return si es que no pasara la validación, en el archivo routes/auth.js

...
  passport.authenticate('basic', function (error, user) {
      try {
        if (error || !user) {
          return next(boom.unauthorized());
        }

Jose Daniel Molina

student•

Pues esto es genial... Pero increíblemente difícil de lograr hacerlo solo... Espero muchas horas de lectura y practica 😤🤯

jorge llanque

student•

¿Como se implementaria un logout?

Luis Lira

student•

Normalmente para la implementación de un logout lo que debes de hacer es limpiar la cookie que se puse también desde el servidor y borrar cualquier estado que le indique a la app que estás logueado. También puedes checar en la documentación de passport, no pongo el link porque no tiene SSL y no me deja hacer el comentario :( pero si pones "passpot.js logout" en Google, lo primero que te saldrá será esa estrategia.

jorge llanque

student•

Perfecto, gracias

Mariela de Jesus Rivas Hernandez

student•

a alguien más le dio este error TypeError: Cannot read property 'scopes' of undefined

Enrique Yael C

student•

algo que me di cuenta es que se puede hacer sign-up dos o mas veces con el mismo correo :/ y a la hora de hacer sign-in es cuando la app deja de funcionar, como verifico que el email no este aun en la bae de datos? alguien sabe?

Gerson Montenegro

student•

Usando bcrypt 5.x la cosa cambia un poquito:

const hashedPassword = await bcrypt.hash(password, 10);

Jorge Velasquez

student•

Para quienes tengan la version 16.1.7 de joi en adelante, deberian hacer un ajuste a la función validate en el validationHandler quedando asi: creditos para Helmer Barcos

functionvalidate(data, schema) {
  const joiSchema = joi.object(schema)
  const { error } = joiSchema.validate(data)
  returnerror
}

Marco Luna

student•

Con la versión 17.1.1 yo lo puse de esta forma:

function validate(data, schema) {
  const { error } = joi
    .object(schema)
    .validate(data, { errors: { stack: true } });
  return error;
}```

Alejandro González Reyes

student•

cuando nos registramos en una api publica, por lo general nos piden insertar una APIKEY para poder hacer peticiones al servicio. MI pregunta es ¿esas llaves se generan de la misma forma que el seeder proporcionado por el profesor, o es una para todos los usuarios, solo que se les entrega a aquellos que asi lo solicitan?

Manuel Ojeda

student•

Tenemos dos tipos de API_KEY La publica y la privada, la publica se puede decir que es la del usuario normal; la privada es la del administrador

Alexis Alberto Texis Auza

student•

Hola,no deberiamos crear un token en base a la apiKey con los permisos publicos y enviarselo ya que una vez que el usuario se registre no tendra un token que enviar donde ademas vienen los scopes,en otras palabras no podra consumir los recursos aunque se haya logueado?

Daniel Esteves

student•

Si, eso se debería hacer cuando el usuario se registre y/o inicie sesión ya que si cierra sesión ese token debería desaparecer

Francisco Javier Gómez Olguín

student•

Por alguna razón, se rompe el validationHandler ... mejor se lo quite ... eso es bueno?

Tomas Goldenberg

student•

EL NUEVO USUARIO TIENE LA API KEY DE ADMIN!! COMO CREAMOS UN USUARIO QUE TENGA PERMISOS DE USUARIO PUBLICO ES DECIR SIN PERMISOS DE ADMINISTRADOR?????

Rubén Santibañez Acosta

student•

En lugar de postman podeis usar una extension de VSC llamada thunder client.

Naldo Duran

student•

✌

Tomas Goldenberg

student•

EL NUEVO USUARIO TIENE PERMISOS DE ADMIN! COMO CREAMOS UN USER CON PERMISOS PUBLICOS?

Diego Forero

Team Platzi•

Cuando se crea el usuario en el backend se puede crear con el isAdmin en false sin importar lo que venga del front y solo un usuario admin puede volver a otro admin.

Tomas Goldenberg

student•

en la peticion post que le envie al backend no le envie el isAdmin. solamente name email password

y aun asi termino con permisos de administrador

Sebastian

student•

Porque en la ruta sign-up obtienes el user directamente del obj Request?

Daniel Ramírez Mendoza

student•

Como tal, lo que está extrayendo es el body del req, y lo renombra a “user”.

const { body: user } = req;

Diego Andres Cabrera Rojas

student•

Esta todo muy genial hasta el momento!!