Sessions & Cookies

1. Cookies and sessions explained

HTTP is stateless: the server forgets you after each response. A cookie is a small name=value pair the server asks the browser to store (Set-Cookie header); the browser sends it back on every later request to that site (Cookie header).

A session keeps the data on the server and puts only a random id in the cookie. The browser holds laravel_session=Abc; the server holds Abc => {user_id: 42, cart_id: 9}. Users cannot read or edit server-side data, and large data never travels with each request.

What travels over the wire

POST /login HTTP/1.1                      (credentials checked)

HTTP/1.1 302 Found
Set-Cookie: laravel_session=eyJpdiI6...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200

GET /orders HTTP/1.1
Cookie: laravel_session=eyJpdiI6...       (browser sends it automatically)

2. Sessions in Laravel

Guest cart merged at login, then session id regenerated

// Adding to cart as a guest
$cart = session('cart', []);
$cart[$product->id] = ($cart[$product->id] ?? 0) + 1;
session(['cart' => $cart]);

// After successful login
public function authenticated(Request $request, User $user)
{
    foreach (session()->pull('cart', []) as $productId => $qty) {
        $user->cartItems()->updateOrCreate(['product_id' => $productId], ['quantity' => DB::raw("quantity + {$qty}")]);
    }
    $request->session()->regenerate();      // new id: blocks session fixation attacks
}

// Logout
Auth::logout();
$request->session()->invalidate();
$request->session()->regenerateToken();     // new CSRF token

Banking settings in config/session.php (via .env)

SESSION_DRIVER=redis          # shared by every app server
SESSION_LIFETIME=10           # minutes idle before logout
SESSION_EXPIRE_ON_CLOSE=true
SESSION_SECURE_COOKIE=true
SESSION_ENCRYPT=true

Flash data (session()->flash("status", "Order placed")) lives for exactly one more request, which is how "saved successfully" messages survive a redirect. Remember-me uses a separate long-lived cookie holding a token that is checked against users.remember_token; turn it off for banking.

3. Sessions with many servers

With the default file driver each server keeps its own session files, so a load balancer that sends the next request to another server logs the user out. Fix it with a shared store (Redis, database, Memcached) or with sticky sessions. Shared storage is preferred because sticky sessions break when a server is removed during a deployment.

Spring Boot: the same with Spring Session + Redis

// build.gradle: implementation 'org.springframework.session:spring-session-data-redis'
// application.yml
// spring.session.store-type: redis
// server.servlet.session.timeout: 10m
// server.servlet.session.cookie: { http-only: true, secure: true, same-site: strict }

@GetMapping("/cart")
public Cart cart(HttpSession session) {
    return (Cart) Optional.ofNullable(session.getAttribute("cart")).orElseGet(Cart::new);
}

4. React SPA: cookies vs storage

A React app on the same site as the Laravel API can simply use the session cookie (Sanctum SPA mode): call /sanctum/csrf-cookie once, then log in, and every fetch with credentials: "include" is authenticated. This is safer than tokens in localStorage because the cookie is HttpOnly.

Sanctum SPA login from React

await fetch('/sanctum/csrf-cookie', { credentials: 'include' });   // sets XSRF-TOKEN cookie
await fetch('/login', {
  method: 'POST',
  credentials: 'include',
  headers: { 'Content-Type': 'application/json', 'X-XSRF-TOKEN': decodeURIComponent(getCookie('XSRF-TOKEN')) },
  body: JSON.stringify({ email, password }),
});
const me = await (await fetch('/api/user', { credentials: 'include' })).json();

5. Interview questions