Cuestionario de 10 pregunatas de opcion multiple para evaluar la comprension de conseptos clave del proyecto en gestion
1
En Astro, ¿por qué conviene usar una ruta dinámica [id].astro para mostrar el detalle de una ficha, en vez de crear una página distinta para cada número de ficha?
2
En el flujo de login de tu proyecto, ¿cuál es el orden correcto?
3
¿Cuál es la diferencia clave entre Deno y Node.js que afecta cómo ejecutas tu backend?
4
El middleware verificarJWT debe ejecutarse antes de la lógica de la ruta router.get("/api/asistencias", verificarJWT, ...). Si Oak lo ejecutara después, ¿qué pasaría exactamente?
5
En un modelo de base de datos relacional, ¿para qué sirve una tabla intermedia (tabla de unión) cuando dos entidades tienen una relación muchos-a-muchos?
6
Un JWT para este proyecto lleva { id, rol, exp } en su payload. ¿Por qué no deberías incluir ahí el password_hash del aprendiz, aunque el token vaya firmado?
7
Dos aprendices usan la misma contraseña "12345". Sus password_hash en MySQL, generados con bcrypt, terminan siendo distintos entre sí. ¿Por qué?
8
El JWT de un aprendiz expira y el backend responde 401 en una petición. Si el frontend en Astro ignora ese error y sigue funcionando como si nada, ¿cuál es la consecuencia más probable?
9
DELETE /api/usuarios/:id debe usarlo solo el admin. Verificar que el JWT sea válido con verify() no es suficiente para garantizar esto. ¿Qué debe agregar el middleware?
10
Un instructor intenta marcar asistencia de un aprendiz que no pertenece a ninguna de sus fichas asignadas. Ocultar el botón en el frontend no es suficiente protección. ¿Dónde y cómo debe repetirse esa validación?
Explicación
Astro lee el parámetro de la URL (el id) en tiempo de build o de request, y con eso consulta los datos de esa ficha específica desde una sola plantilla [id].astro. Así evitas duplicar código para cada ficha — es el propósito mismo de las rutas dinámicas. (No hay límite de 10 páginas, y las rutas dinámicas no son obligatorias, solo convenientes aquí.)
El backend nunca debe confiar en que el frontend valide algo sensible como una contraseña — cualquiera podría manipular el frontend. Por eso el flujo correcto es: el frontend solo envía los datos, y es el backend quien los compara contra MySQL y decide si emite el JWT. MySQL no genera tokens, solo almacena datos.
Es la diferencia de diseño más importante entre ambos runtimes: Node ejecuta código con acceso total por defecto, mientras que Deno bloquea red/archivos/env hasta que tú los permites explícitamente con flags. Deno sí soporta JavaScript puro, y sí puede conectarse a MySQL (por eso instalamos el driver mysql de Deno).
Un middleware solo protege lo que viene después de él en la cadena. Si verificarJWT se ejecutara después de la lógica de la ruta, esa lógica ya se habría ejecutado y respondido — el middleware llegaría tarde, sin sentido.
Una relación muchos-a-muchos no se puede representar con una sola llave foránea en ninguna de las dos tablas (porque cada lado puede tener varios vínculos con el otro). La tabla intermedia resuelve esto guardando cada combinación válida como una fila propia, con una llave foránea hacia cada una de las dos tablas originales.
Un JWT está firmado (para que no se pueda alterar sin ser detectado) pero no está encriptado — su payload es solo texto codificado en Base64, que cualquiera puede leer en sitios como jwt.io sin necesitar la clave secreta. Por eso nunca debe llevar contraseñas ni datos sensibles.
bcrypt genera un valor aleatorio (salt) distinto cada vez que hashea una contraseña, y lo incorpora al resultado final. Así, aunque el texto plano sea idéntico, el hash resultante nunca es igual. Esto frustra ataques con tablas precalculadas (rainbow tables), porque un atacante no puede simplemente comparar hashes conocidos.
Si el frontend no reacciona al 401, sigue mostrando una interfaz que depende de datos que nunca llegaron (porque el backend rechazó la petición) — el usuario ve algo roto o vacío sin ninguna pista de qué pasó ni cómo arreglarlo. Lo correcto es capturar ese 401 y redirigir al login.
verify() solo confirma que el token es auténtico y no expiró — es decir, comprueba autenticación. Pero no dice nada sobre si ese usuario tiene permiso para esa acción específica — eso es autorización, y se resuelve revisando el campo rol que va dentro del payload del JWT.
El frontend es código que corre en el navegador del usuario, así que puede inspeccionarse y manipularse (herramientas de desarrollador, Postman, etc.) para saltarse cualquier validación visual. La única validación que realmente protege los datos es la que ocurre en el servidor: antes de guardar la asistencia, el backend debe cruzar el instructor_id que viene en el JWT contra la tabla ficha_asignaturas, confirmando que esa ficha/asignatura de verdad le pertenece a ese instructor.
|
Test your knowledge about the 5 seeing habits discussed in the text 'UPS 5 seeing habits'.
Tissues - Practice Quiz