Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/interezante456-pixel/nuevo-proyecto-viernes/llms.txt

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

AccesoController is the authentication gateway for Tienda Mi Cholo. It handles displaying and processing the login form, setting up the ASP.NET Core cookie authentication principal and the server-side session, signing out, and rendering the access-denied page for users who attempt to reach a route their role does not permit. Unlike every other controller in the application, AccesoController does not carry a class-level [Authorize] attribute — the login and access-denied actions must be reachable by unauthenticated visitors. The default route configured in Program.cs points to Acceso/Login, so the login page is the application entry point.
AccesoController carries [ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)] at the class level, so every action in the controller inherits the no-cache directive. This instructs the browser never to cache any response from this controller, which prevents a logged-out user from navigating back to a cached version of the login page.

​
LoginVM Model

The login form is bound to the LoginVM view model defined in Final_proyecto.ViewModels: 
namespace Final_proyecto.ViewModels
{
    public class LoginVM
    {
        public string Correo { get; set; }
        public string Contraseña { get; set; }
    }
}

​
Actions

​
GET /Acceso/Login

Renders the login form view. No authentication required. Authorization: Public (no [Authorize] attribute).

​
POST /Acceso/Login

Validates the submitted credentials, builds the cookie authentication principal, writes four session keys, and redirects the user to the home page on success. Authorization: Public (no [Authorize] attribute).
​
Correo
string
required
The user’s email address. Matched against Usuario.CorreoUsuario in the database.
​
Contraseña
string
required
The user’s password. Matched against Usuario.Contraseña in the database using a direct equality comparison.
Passwords are stored and compared as plain text. There is no hashing or salting. This is only appropriate for development or internal-only deployments. Before exposing the application externally, replace the comparison with a proper password hashing scheme such as BCrypt or ASP.NET Core’s IPasswordHasher<T>.
Validation steps performed:
  1. Query Usuarios (with Rol included) where CorreoUsuario == loginVM.Correo AND Contraseña == loginVM.Contraseña.
  2. If no match → sets ViewData["Mensaje"] = "Correo o contraseña incorrectos" and returns the login view.
  3. If usuario.Estado == false → sets ViewData["Mensaje"] = "Su cuenta está desactivada. Contacte al administrador." and returns the login view.
Claims written to the cookie principal on success: 
var claims = new List<Claim>()
{
    new Claim(ClaimTypes.Name,  usuario.NomUsuario),
    new Claim(ClaimTypes.Email, usuario.CorreoUsuario),
    new Claim(ClaimTypes.Role,  usuario.Rol.NomRol),
    new Claim("IdUsuario",      usuario.ID_Usuario.ToString()),
    new Claim("NomCompleto",    usuario.NomCompleto)
};
The principal is signed in with CookieAuthenticationDefaults.AuthenticationScheme and IsPersistent = true, AllowRefresh = true. Session keys written on success:
KeyValue
"Usuario"usuario.NomUsuario
"NomCompleto"usuario.NomCompleto
"Rol"usuario.Rol.NomRol
"IdUsuario"usuario.ID_Usuario (stored as int)
The IdUsuario session integer is read by VentaController.Nueva when recording which user created the sale: HttpContext.Session.GetInt32("IdUsuario") ?? 1.
On success: Redirects to GET /Home/Index.

​
/Acceso/Logout

Clears all session data, signs out the cookie authentication scheme, and redirects the user back to the login page.
The Logout action has no [HttpGet] or [HttpPost] attribute in the source code, so ASP.NET Core’s routing accepts any HTTP method for this path. It is conventionally called via a link (GET), but the action itself does not restrict the HTTP verb.
Authorization: No explicit [Authorize] attribute — the action is reachable without authentication, though in practice it is only linked to from within the authenticated layout. 
HttpContext.Session.Clear();
await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
return RedirectToAction(nameof(Login));
On success: Redirects to GET /Acceso/Login.

​
GET /Acceso/Registro

Returns an immediate redirect to GET /Acceso/Login. Self-registration is disabled in the application; the route exists as a stub to handle any inbound link or form that targets /Acceso/Registro. Authorization: Public (no [Authorize] attribute). 
[HttpGet]
public IActionResult Registro()
{
    return RedirectToAction(nameof(Login));
}

​
POST /Acceso/Registro

Also redirects immediately to GET /Acceso/Login. The UsuarioVM model parameter is accepted by the binder but the body is never read or processed. New user accounts must be created by an administrator through the user management module. Authorization: Public (no [Authorize] attribute). 
[HttpPost]
public IActionResult Registro(UsuarioVM usuarioVM)
{
    return RedirectToAction(nameof(Login));
}
Both GET and POST /Acceso/Registro are intentional no-op stubs. If you navigate to /Acceso/Registro directly or submit a registration form, you will be redirected to the login page without any feedback message.

​
GET /Acceso/AccesoDenegado

Renders the access-denied view. This route is configured in Program.cs as the AccessDeniedPath for the cookie authentication scheme, so ASP.NET Core redirects here automatically whenever an authenticated user attempts to reach an action whose [Authorize(Roles = "...")] attribute does not include their role. Authorization: No explicit attribute — reached via ASP.NET Core’s internal redirect for role failures. 
// Program.cs configuration
.AddCookie(options =>
{
    options.LoginPath        = "/Acceso/Login";
    options.AccessDeniedPath = "/Acceso/AccesoDenegado";
});

Build docs developers (and LLMs) love

Get started for freeTalk to us