The Sessions Framework

A session is server-side storage that remembers data about one visitor across many requests, keyed by an opaque identifier the browser keeps in a cookie.

Learn The Sessions Framework in our free Django course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.

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

In this lesson you'll use request.session like a dictionary — setting, reading, and popping values — control how long sessions live with SESSION_COOKIE_AGE , learn where Django stores them, and flush a session cleanly on logout.

The sessions framework is enabled by default — SessionMiddleware is in MIDDLEWARE and django.contrib.sessions is in INSTALLED_APPS . Inside any view you get request.session , which behaves like a Python dictionary. You set keys, read them with an optional default, and Django saves the changes automatically.

The classic session example is a counter that survives reloads. You read the current value with get("visits", 0) , add one, and write it back. For data that should appear exactly once — like a "Saved!" notice — use pop() , which reads the value and removes it in a single step.

A session does not last forever. SESSION_COOKIE_AGE sets the lifetime in seconds (default two weeks). You choose where the data lives with SESSION_ENGINE : the database (default), the cache for speed, files, or a signed cookie that stores the data in the browser itself.

On logout you should throw the session data away. request.session.flush() deletes the stored data and rotates the key so the old one is useless — Django's built-in logout() view does this for you.

A visit counter must start at zero the first time, before any value exists in the session. Fill in the blank with the default that makes the count read 1, 2, 3.

You used request.session["cart"] on a visitor who never set it.

✅ Fix: read with a default — request.session.get("cart", []) .

❌ My in-place change to a list/dict isn't saved

request.session["cart"].append(x) mutates the list but Django doesn't notice.

✅ Fix: set request.session.modified = True , or reassign the whole value back.

The database session backend needs its table, which you haven't created yet.

✅ Fix: run python manage.py migrate so django_session exists.

Build a shopping cart that lives in the session: add items, count them, and clear the cart on checkout — exactly the pattern you'd use with request.session .

Lesson complete — your app remembers its visitors!

You can use request.session like a dictionary, set and pop values, build a visit counter and flash messages, control expiry with SESSION_COOKIE_AGE , choose a storage backend, and flush a session cleanly on logout.

🚀 Up next: File & Image Uploads — accept files from users and store them with FileField and request.FILES .

Practice quiz

What is a Django session?

  • Server-side storage that remembers data across requests
  • A single HTTP request
  • A database migration
  • A URL route

Answer: Server-side storage that remembers data across requests. A session is server-side storage keyed by an identifier the browser keeps in a cookie.

How do you interact with the session inside a view?

  • request.cookies
  • request.session
  • request.store
  • request.state

Answer: request.session. request.session behaves like a dictionary you set and read in a view.

Which is the safe way to read a session value that might not exist?

  • key

request.session.get('key', default) avoids a KeyError when the key is missing.

Which method reads a value and removes it in one step?

  • get()
  • set()
  • keys()
  • pop()

Answer: pop(). request.session.pop('flash', None) reads and removes a key, ideal for one-time data.

Which setting controls how long a session lasts, in seconds?

  • SESSION_TIMEOUT
  • SESSION_COOKIE_AGE
  • SESSION_LIFETIME
  • COOKIE_MAX_AGE

Answer: SESSION_COOKIE_AGE. SESSION_COOKIE_AGE sets the session lifetime in seconds (default 1209600, two weeks).

What is the default session storage backend?

  • The database (django_session table)
  • The file system
  • A signed cookie
  • Redis

Answer: The database (django_session table). By default Django uses the database backend, storing each session as a row in django_session.

Which method deletes session data and rotates the key on logout?

  • request.session.clear()
  • request.session.delete()
  • request.session.flush()
  • request.session.reset()

Answer: request.session.flush(). flush() deletes the data and rotates the key; Django's logout() view calls it.

When you mutate a list stored in the session in place, what must you do so it saves?

  • Nothing, it always saves
  • Restart the server
  • Run migrate
  • Set request.session.modified = True

Answer: Set request.session.modified = True. Django cannot detect in-place mutations; set session.modified = True or reassign the value.

What does the browser actually hold with the default session backend?

  • An opaque session key in a cookie
  • The full session data
  • The user's password
  • Nothing at all

Answer: An opaque session key in a cookie. The browser only holds an opaque session key; the real data stays on the server.

Which setting, when True, ends the session when the browser closes?

  • SESSION_COOKIE_AGE
  • SESSION_EXPIRE_AT_BROWSER_CLOSE
  • SESSION_SAVE_EVERY_REQUEST
  • SESSION_COOKIE_SECURE

Answer: SESSION_EXPIRE_AT_BROWSER_CLOSE. SESSION_EXPIRE_AT_BROWSER_CLOSE=True makes the session end when the browser is closed.