Sessions Advanced

By the end of this lesson you'll move sessions out of single-server files and into shared storage with a custom handler, tune and secure the session cookie, avoid the locking trap that slows AJAX pages, defend against fixation and hijacking, and weigh stateless JWTs against server-side sessions.

Learn Python, JavaScript, Java and more with free interactive lessons, real projects and AI-powered help. Beginner-friendly.

Part of the free Php course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

What You'll Learn in This Lesson

1️⃣ Custom Session Handlers (scaling across servers)

PHP's default sessions are files saved on the one server that handled the request. The moment you run a second server behind a load balancer — a router that spreads traffic across machines — the next request can hit a different box where that file doesn't exist, and the user looks logged out. The fix is to store sessions somewhere every server can reach. You do that by implementing SessionHandlerInterface : a class with six methods PHP calls for you ( open , close , read , write , destroy , gc ), then registering it with session_set_save_handler() before session_start() .

From your code's point of view nothing changes — you still read and write $_SESSION exactly as before. PHP simply routes the storage through your handler. The gc() method is your cleanup: PHP calls it occasionally to delete expired rows so the table doesn't grow forever.

2️⃣ Redis Sessions & Configuration

Redis is an in-memory data store, which makes it the fastest session backend. The best part: PHP ships with a Redis session handler, so you usually write no code at all — you just point session.save_handler and session.save_path at your Redis server. Beyond the backend, a handful of session.* settings control how long data lives ( gc_maxlifetime ) and how the cookie behaves ( cookie_lifetime , cookie_httponly , cookie_secure , cookie_samesite ). Set them before session_start() .

3️⃣ Session Locking & the Read-then-Write-Close Pattern

Here's a trap that surprises everyone. While a request holds the session open, PHP locks it so two requests can't clobber the data by writing at once. Any other request from the same user waits until the first one finishes or calls session_write_close() . On a page firing several AJAX calls together, they quietly run one-after-another instead of in parallel — and it just feels slow. The cure is the read-then-write-close pattern: do all your $_SESSION writes up front, call session_write_close() to release the lock, then do the slow work.

After session_write_close() you can still read $_SESSION from memory — you just can't save changes to storage. So write first, close, then read freely while the heavy lifting happens unblocked.

4️⃣ Session Security: Fixation & Hijacking

Two attacks target sessions directly. In fixation , an attacker plants a session id they already know on a victim (say, via a link); when the victim logs in, the attacker shares that authenticated session. The single defence is to issue a fresh id the moment privileges change — session_regenerate_id(true) right after login, where true deletes the old session. In hijacking , an attacker steals a valid session id (often via XSS or an insecure cookie). You raise the bar by binding the session to a fingerprint — the client's IP and user-agent — and dropping it if that fingerprint suddenly changes.

Pair this with the secure cookie flags from Section 2 ( HttpOnly stops JavaScript reading the cookie, Secure keeps it on HTTPS, SameSite blunts CSRF) and most session attacks lose their footing.

5️⃣ Stateless Alternatives (JWT) & Trade-offs

There's a different model entirely: store nothing on the server. A JWT (JSON Web Token) is a small signed token the client carries in a cookie or header. Because it's signed with a secret using hash_hmac , the server can verify it wasn't tampered with — no database lookup needed. That scales effortlessly and suits APIs. The catch is real: you can't instantly revoke a JWT (it's valid until it expires), and stuffing data into it bloats every request. Server-side sessions are the mirror image — easy to revoke (delete the row), tiny cookie — but they need shared storage. Verify signatures with hash_equals() , which is timing-safe; never use === .

Now you try. The login below is almost complete — fill in each ___ using the 👉 hint, then run it and check it against the Output panel.

One more — the locking pattern in practice. Add the call that releases the lock before the slow work, following the 👉 hint.

📋 Quick Reference — Advanced Sessions

No code is filled in this time — just a brief and an outline. Build a minimal stateless token from scratch, run it on onecompiler.com/php or your own machine, then check your result against the expected output in the comments. This is the same sign-then-verify loop every JWT library does under the hood.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary