Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/LuisAMoralesA/tallerIngles-UAEMEcatepec/llms.txt

Use this file to discover all available pages before exploring further.

The system provides three independent login portals, each handling a single role. All passwords are hashed with SHA-256 before storage and comparison — plain-text passwords are never stored or transmitted to the users table. Session-based authentication persists for 30 minutes of inactivity, after which the server invalidates the session automatically.

​
Portales de inicio de sesión

Each role has a dedicated JSP login form and a dedicated servlet that validates credentials against the users table using the rango column as a role discriminator.
RolURL del portalServletRango en BD
Administrador/view/login/loginAdministrador.jspGET|POST /loginAdminADMINISTRADOR
Profesor/view/login/loginProfesor.jspGET|POST /loginTeacherPROFESOR
Alumno/view/login/loginAlumno.jspGET|POST /loginStudentESTUDIANTE
All three login portals are linked in the public navigation bar so users can reach the correct portal from any login page.

​
Flujo de autenticación

1

User submits credentials via POST form

The user enters their username (user) and password (pass) into the login form and clicks Ingresar. The form submits via POST to the role-specific servlet (e.g., /loginAdmin). The servlet processes both GET and POST through a shared processRequest method, and only acts when the submit parameter is present.
2

Password is hashed with SHA-256

Before any database call is made, the servlet hashes the submitted password using SHA256.contraseñaNueva(). This produces a lowercase hexadecimal string that matches the format stored in the database at registration time.
3

Database lookup with role check

BaseDatos.inicioSesion(user, hashedPass, rango) issues a SELECT against the users table filtered by both nom_user and rango. This means a teacher’s username will not match on the admin portal even if the credentials are otherwise valid — each portal is role-isolated.
4

Switch on the integer result code

The method returns one of three integer constants from BaseDatos.constantesLogin:
ConstantValueMeaningAction
ACCESO_CONCEDIDO3Username and hashed password both matchCreates HttpSession, sets sesionIniciada attribute to the username, redirects to the role dashboard
USUARIO_NO_ENCONTRADO2Username not found for this roleSets errorMessage in session, redirects back to the login portal
DATO_INCORRECTO1Username matched but the hash did notSets errorMessage in session, redirects back to the login portal

​
Hash de contraseñas (SHA-256)

The SHA256 class wraps the standard java.security.MessageDigest API. It implements the SHA256Struct interface and exposes a single method, contraseñaNueva(String pass), which computes the SHA-256 digest and converts the resulting byte array to a lowercase hex string using String.format("%02x", b) for each byte. The method throws a RuntimeException wrapping the underlying NoSuchAlgorithmException if (in theory) the JVM does not support SHA-256 — this is never expected in practice on any compliant Jakarta EE runtime. The following excerpt from loginAdmin.java shows exactly how the class is used at login time:
loginAdmin.java
SHA256 hash = new SHA256();
String pass = hash.contraseñaNueva(request.getParameter("pass"));
int resultado = base.inicioSesion(user, pass, "ADMINISTRADOR");
The SHA256.contraseñaNueva() method computes the SHA-256 digest and returns a hex string. Passwords are never stored in plain text. The same method is called at registration time so that stored and compared hashes are always produced by the same algorithm.

​
Nombre de usuario auto-generado (alumnos)

When an administrator enrolls a new student through the addStudent servlet, no manual username is entered. Instead, the username is deterministically generated from the student’s personal data at enrollment time. All name components are uppercased via .toUpperCase() before slicing.
addStudent.java
String apaterno = request.getParameter("apaterno").toUpperCase();
String amaterno = request.getParameter("amaterno").toUpperCase();
String name     = request.getParameter("name").toUpperCase();
String birthdate = request.getParameter("birthdate"); // format: YYYY-MM-DD

String nomUsuario = apaterno.substring(0,2) + amaterno.substring(0,1) + name.substring(0,3)
                  + birthdate.substring(2,4) + birthdate.substring(5,7) + birthdate.substring(8,10);
// Example: MOAVAL + 990115 → MOAVAL990115
The format is:
SegmentSourceLength
First 2 chars of paternal surname (apaterno)e.g. MORALES → MO2
First 1 char of maternal surname (amaterno)e.g. AVILA → A1
First 3 chars of given name (name)e.g. VALERIA → VAL3
Year digits YY (birthdate[2:4])e.g. 1999-01-15 → 992
Month digits MM (birthdate[5:7])e.g. 1999-01-15 → 012
Day digits DD (birthdate[8:10])e.g. 1999-01-15 → 152
Total: 12 characters, all uppercase letters and digits. This username is then stored in the users table as nom_user and shown to the administrator via the userNameRegistrado session attribute after successful registration.

​
Errores de autenticación

The submitted username does not exist in the users table for the role associated with the portal being used. This can mean:
  • The username was never created.
  • The user registered under a different role (e.g., a teacher’s username entered on the student portal).
  • The username was typed incorrectly (case matters — usernames are stored with the exact casing produced by the auto-generation or manual entry).
The servlet sets session.setAttribute("errorMessage", "Usuario no encontrado") and redirects back to the login page. The JSP reads this attribute via session.getAttribute("errorMessage") and displays it through the SweetAlert error modal.
The username was found in the users table with the correct role, but the SHA-256 hash of the submitted password does not match the stored hash. Common causes:
  • The user typed the wrong password.
  • The password was set or reset using a different encoding or capitalisation.
  • A manual database entry was made with an unhashed or differently-hashed password.
The servlet sets session.setAttribute("errorMessage", "La contraseña ingresada es incorrecta") and redirects back to the login page. Check that the password was originally set through the TEI registration flow so that the same SHA256.contraseñaNueva() method was used to produce the stored hash.

Build docs developers (and LLMs) love

Get started for freeTalk to us