User Login

Overview

User login is the process of verifying a user’s identity and granting access to the system. The server receives the user’s credentials, looks up the account in the database, verifies the password against the stored hash, and creates a session if the credentials are valid.

The key steps are:

1. User submits credentials (email/username + password).
2. Server looks up the user in the database.
3. Server verifies the password against the stored hash.
4. If valid, the server creates a session.
5. User is redirected to a protected page.

---

Login Form Design

A practical approach is to use a single “identifier” field that accepts either an email address or a username, combined with a password field. This gives users the flexibility to log in with whichever they prefer, without requiring two separate forms.

---

Password Verification

When verifying passwords, always use password_verify(). Never compare hashes directly.

The wrong approaches:

• Comparing plain text to a hash ($password === $hash) will never work because they are completely different strings.
• Hashing the input and comparing (password_hash($input) === $hash) will also fail because each call to password_hash() produces a unique hash due to the random salt.

The correct approach is to use password_verify($plainPassword, $storedHash). This function extracts the salt from the stored hash, applies it to the input password, and performs a constant-time comparison that prevents timing attacks.

---

Authentication Process

The authentication logic follows this pattern:

1. Try to find the user by email first, then by username.
2. If no user is found, return null (invalid credentials).
3. Use password_verify() to compare the submitted password with the stored hash.
4. If the password matches, return the user data. Otherwise, return null.

Always return the same generic response for any authentication failure. Do not say “Email not found” (which reveals that the email is not registered) or “Wrong password” (which confirms the email exists). Always respond with “Invalid credentials” to prevent user enumeration attacks.

---

Session Data

After a successful login, store the following data in the session:

• user_id - the database ID
• user_email - the email address
• user_name - the full name for display
• user_role - for authorization checks (admin/customer)
• is_authenticated - a boolean flag set to true

Storing this data avoids querying the database on every request and enables quick access to user information for display and authorization. Session data is stored on the server; only the session ID is sent to the browser as a cookie.

---

Login Flow

┌─────────────────┐
│  User enters    │
│  email/username │
│  + password     │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Validate input │
│  (required?)    │
└────────┬────────┘
         │
    ┌────┴────┐
    │         │
    ▼         ▼
  Valid    Invalid
    │         │
    │         └──> Show error,
    │              redirect back
    ▼
┌─────────────────┐
│  Find user by   │
│  email/username │
└────────┬────────┘
         │
    ┌────┴────┐
    │         │
    ▼         ▼
  Found    Not Found
    │         │
    │         └──> "Invalid credentials"
    ▼              redirect back
┌─────────────────┐
│  Verify password│
│  password_verify│
└────────┬────────┘
         │
    ┌────┴────┐
    │         │
    ▼         ▼
  Match    No Match
    │         │
    │         └──> "Invalid credentials"
    │              redirect back
    ▼
┌─────────────────┐
│  Create session │
│  - user_id      │
│  - user_role    │
│  - is_auth=true │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Redirect based │
│  on role:       │
│  Admin > /admin │
│  User > /dash   │
└─────────────────┘

---

Protecting Routes with Middleware

Middleware is code that runs before your route handler, acting as a gatekeeper. It intercepts every request and decides whether to allow it through or redirect the user.

User Request > Middleware > Route Handler > Response
                   |
            Check session
                   |
          Is authenticated?
            /         \
          Yes         No
           |           |
     Continue    Redirect to login

An AuthMiddleware checks whether the session variable is_authenticated is set to true. If it is, the request proceeds to the route handler. If not, the user is redirected to the login page with an error message.

---

Role-Based Access Control

Authorization goes one step further than authentication by restricting access based on user roles.

Two levels of middleware provide this:

1. AuthMiddleware checks if the user is logged in (any role).
2. AdminAuthMiddleware checks if the user is logged in and has the admin role.

The AdminAuthMiddleware logic works as follows: if the user is not authenticated, redirect to login. If the user is authenticated but is not an admin, redirect to the user dashboard with an “Access denied” message. If the user is authenticated and is an admin, grant access.

Access Control Matrix

Route	Not Logged In	Customer	Admin
/login	Allow	Allow	Allow
/register	Allow	Allow	Allow
/dashboard	Redirect to login	Allow	Allow
/admin/dashboard	Redirect to login	Denied	Allow
/admin/users	Redirect to login	Denied	Allow

Public routes have no middleware. User routes use AuthMiddleware. Admin routes use AdminAuthMiddleware, which also checks authentication.

---

Security Considerations

Several security practices are built into this login process:

• Use prepared statements for all database queries to prevent SQL injection.
• Return consistent “Invalid credentials” messages so attackers cannot determine whether a specific email or username exists.
• Configure session cookies with httponly (prevents JavaScript access), secure (HTTPS only), samesite (CSRF protection), and regenerate the session ID periodically.
• Consider rate limiting login attempts per IP or user to mitigate brute-force attacks.