Accounts and logins

Sessions: remembering who's signed in

HTTP has no memory: each request arrives on its own. After a successful login, the app needs a way to recognize the next request from the same browser. Flask's session does it with a cookie. You use session like a dictionary, and Flask stores its contents in a cookie signed with app.secret_key.

Signed is not secret. The person can read everything in the cookie; they just can't change it without breaking the signature. See for yourself:

import base64
from flask import Flask, session

app = Flask(__name__)
app.secret_key = "practice-only-key"

@app.route("/login-as/<int:user_id>")
def login_as(user_id):
    session["user_id"] = user_id
    return "ok"

@app.route("/whoami")
def whoami():
    return f"user {session.get('user_id')}"

client = app.test_client()
client.get("/login-as/7")
cookie = client.get_cookie("session").value
payload, timestamp, signature = cookie.split(".")
print("cookie:", cookie)
print("anyone can read it:", base64.urlsafe_b64decode(payload + "=" * (-len(payload) % 4)))
print(client.get("/whoami").get_data(as_text=True))

forged = base64.urlsafe_b64encode(b'{"user_id":1}').decode().rstrip("=")
client.set_cookie("session", f"{forged}.{timestamp}.{signature}")
print("after tampering:", client.get("/whoami").get_data(as_text=True))

The forged cookie claims to be user 1, but its signature doesn't match, so Flask ignores it and the session comes back empty. Two rules follow. Keep secret_key long, random and out of your code (an environment variable), because anyone who has it can sign any cookie they like. And store only an identifier in the session, never a password, a hash or anything private.

Sign up, log in, log out

With hashing and sessions in place, the three views are short. The details are what make them safe:

• Sign up: validate the email and password, refuse an email that's already registered, store the bcrypt hash, then log the new user in.
• Log in: look the user up, check the password with bcrypt.checkpw, and answer the same message whether the email is unknown or the password is wrong ("Wrong email or password."). Different messages would tell an attacker which emails have accounts.
• Before logging someone in, clear the session with session.clear(). Otherwise an attacker who planted a session cookie in the victim's browser (session fixation) would share the signed-in session.
• Log out with a POST (a link someone else could trigger is a GET) and clear the session.

Pages that need a login check the session first and send visitors to the login page. A decorator, from the decorators lesson, keeps that check in one place:

from functools import wraps

def login_required(view):
    @wraps(view)
    def wrapper(*args, **kwargs):
        if "user" not in session:
            return redirect(url_for("login"))
        return view(*args, **kwargs)
    return wrapper

@app.route("/dashboard")
@login_required
def dashboard():
    ...

@wraps keeps the view's name, which Flask uses as the endpoint for url_for. Without it, every protected view would be called "wrapper", and Flask would refuse to register a second one.

A common extra is /login?next=/settings, which returns people to the page they wanted. Only follow next if it's a path on your own site (it starts with a single /), or your login page becomes an open redirect that sends your users to a look-alike site after they sign in.

Settings and limits worth knowing

Flask's defaults are good, and a few settings make sessions tighter in production:

• SESSION_COOKIE_HTTPONLY = True (the default) hides the cookie from JavaScript, so an injected script can't read it.
• SESSION_COOKIE_SECURE = True sends the cookie only over HTTPS. Turn it on wherever the site uses HTTPS, which should be everywhere.
• SESSION_COOKIE_SAMESITE = "Lax" keeps the cookie off most cross-site POSTs, a second layer against CSRF.
• PERMANENT_SESSION_LIFETIME limits how long a "remember me" session lasts.

Login pages also need a limit on attempts per account and per address, or an attacker can simply try passwords all day; the reliability lesson shows how rate limiting works. Larger apps often hand all of this to a library such as Flask-Login, or to an identity provider with "Sign in with ..." buttons. Even then, knowing what happens underneath is what lets you configure them correctly and review their use.

from flask import Flask, session, g, redirect, url_for

USERS = {"ada@example.com": {"name": "Ada", "role": "admin"}, "lin@example.com": {"name": "Lin", "role": "member"}}

app = Flask(__name__)
app.secret_key = "practice-only-key"

@app.before_request
def load_user():
    g.user = USERS.get(session.get("user"))

@app.route("/test-login/<email>")
def test_login(email):
    session.clear()
    session["user"] = email
    return "ok"

@app.route("/admin")
def admin():
    if g.user is None:
        return redirect(url_for("test_login", email="?"))
    if g.user["role"] != "admin":
        return "Admins only", 403
    return f"Welcome to the admin page, {g.user['name']}"

for who in [None, "lin@example.com", "ada@example.com"]:
    client = app.test_client()
    if who:
        client.get(f"/test-login/{who}")
    reply = client.get("/admin")
    print(who, "->", reply.status_code, reply.get_data(as_text=True)[:60])