Inleiding¶

Tijdens deze les volgen we (grotendeels) de officiële Flask tutorial. Die zit goed in elkaar, gebruikt van alle belangrijkste functies, en je kan er gemakkelijk online extra informatie over vinden.

Tijdens de tutorial maken we een eenvoudige blog applicatie, "Flaskr". Gebruikers zullen kunnen registreren, inloggen en hun eigen posts maken, aanpassen of verwijderen.

Flask is erg flexibel en je kan een project op verschillende manieren organiseren. De tutorial geeft een gestructureerd voorbeeld waar heel wat best-practices in verweven zitten.

Project Layout en Initialisatie¶

Project nieuwe directory aanmaken¶

mkdir flask-tutorial
cd flask-tutorial

Alle paden en bestandsnamen die we vanaf nu gebruiken zijn relatief t.o.v. deze directory.

uv of conda environment initialiseren¶

uv init
uv add "Flask~=3.0"

conda create -n flask
conda activate flask
conda install "Flask~=3.0"

conda activate flask

.gitignore file toevoegen¶

Als je uv gebruikt dan is de standaard .gitignore een prima start. We voegen *.sqlite zodat we nooit de database bestand(en) willen committen.

# Python-generated files
__pycache__/
*.py[oc]
build/
dist/
wheels/
*.egg-info

# Virtual environments
.venv

# SQLite database files
*.sqlite

Git initialiseren¶

git init
git add .
git commit -m "Project init"

Zoals bij elke project doe je er goed aan regelmatig je vooruitgang de committen.

Project Structuur¶

Het project krijgt de volgende basis-structuur:

./flask-tutorial
├── flaskr/          # (1)
│   ├── __init__.py  # (1)
│   ├── templates/   # (2)
│   └── static/      # (3)
└── tests/           # (4)

1. flaskr is een Python package voor de applicatie
2. in templates/ komen alle jinja2 templates
3. in static/ komen alle statische elementen zoals css, afbeeldingen, ...
4. in tests/ komen later de unit tests

Application Setup¶

We weten al dat we één enkele instance van de Flask class zullen hebben, typisch app genoemd. In plaats van dit object rechtstreeks aan te maken (zoals we tot nu toe gedaan hebben) gebruiken we het Factory Pattern. Hierbij maken we een aparte functie die het Flask object terug geeft. Dat is handig om het uiteindelijke object anders te configureren naargelang de omgeving (tests, productie, ...).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

from flask import Flask

def create_app() -> Flask: # (1)
    app = Flask(__name__) # (2)
    app.secret_key = "dev" # (3)
    app.jinja_options["autoescape"] = True # (4)

    @app.route("/ping") # (5)
    def ping():
        return "pong" # (5)

    return app

1. Flask verwacht ofwel een globale app variabele, ofwel een create_app factory functie. We zullen dus nergens create_app expliciet moeten aanroepen.
2. Als eerste stap moeten we natuurlijk een Flask app object maken.
3. Omdat we cookies willen gebruiken (via het flask.session object) hebben we een key nodig. Om te starten gebruiken we een dummy key maar later moeten we dit beter beveiligen.
4. Voor het renderen van Jinja templates willen we altijd autoescape gebruiken. Op deze manier kunnen we onze templates de extensie .html.j2 geven.
5. We voegen direct een simpele test-route toe aan de applicatie. Deze code kan je later verwijderen.

We testen de functie direct uit. Merk op dat Flask automatisch de create_app functie in de module uitvoert.

$ flask --app flaskr run --debug
 * Serving Flask app 'flaskr'
 * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:5000
Press CTRL+C to quit
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 644-305-120
 ```

# Database Toegang

De applicatie zal een SQLite database gebruiken om de gebruikers en hun posts op de slaan. Zoals bij de meeste andere databases zullen we een `Connection` object nodig hebben om met de database te werken.

## Database Connection

Met de volgende module voorzien we _helper-functions_ om op een slimme manier een database connection te verkrijgen en ook terug af te sluiten.

Deze module is ook een mooi voorbeeld van het gebruik van de `g` en `current_app` proxies uit [Les 1 - De Application Context](1_inleiding.md#de-application-context).

```python title="flaskr/db.py" linenums="1"
import sqlite3
from pathlib import Path
from flask import g

LOCAL_DIRECTORY = Path(__file__).parent # (1)
SQLITE_DB_FILE = LOCAL_DIRECTORY / "flaskr.sqlite" # (1)

def get_db() -> sqlite3.Connection:
    if "db" not in g: # (2)
        g.db = sqlite3.connect(SQLITE_DB_FILE) # (3)
        g.db.row_factory = sqlite3.Row # (4)
    return g.db

def close_db(_exc=None):
    if "db" in g:
        g.db.close() # (5)

1. pathlib is een handige module uit the Python standard library om met bestanden en directories te werken. Met Path(__file__).parent krijgen we de directory waar db.py zich bevindt. Op die manier zijn we zeker dat we altijd met hetzelfde sqlite bestand werken.
2. De sqlite3.Connection voor een bepaalde Request wordt bewaard in het flask.g object. Op die manier wordt er maar één connection per request aangemaakt.
3. Om eenvoudig te starten gebruiken we vast SQLite database bestand. Later zullen we dit configureerbaar willen maken.
4. Deze configuratie zorgt ervoor dat de sqlite3.Connection rows zal returnen als dictionaries i.p.v. tuples. Dit is iets handiger om met de data te werken.
5. Enkel als een connection bestaat proberen we deze te sluiten. We zien later hoe ervoor gezorgd wordt dat deze functie op het einde van elke request wordt uitgevoerd.

Tables¶

We gebruiken standaard SQL commando's om de tables in de SQLite database aan te maken. We hebben maar 2 tables nodig, één om de gebruikers op de slaan, en één voor de blogposts.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

DROP TABLE IF EXISTS user;
DROP TABLE IF EXISTS post;

CREATE TABLE user (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  username TEXT UNIQUE NOT NULL,
  password TEXT NOT NULL
);

CREATE TABLE post (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  author_id INTEGER NOT NULL,
  created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  title TEXT NOT NULL,
  body TEXT NOT NULL,
  FOREIGN KEY (author_id) REFERENCES user (id)
);

We breiden db.py uit zodat we het kunnen uitvoeren om bovenstaande schema toe te passen op een SQLlite database.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# bestaande code...

def init_db():
    db = sqlite3.connect(SQLITE_DB_FILE) # (1)

    with open(LOCAL_DIRECTORY / "schema.sql") as schema: # (2)
        db.executescript(schema.read()) # (2)

    print("SQLite schema created. Tables in DB:")
    result = db.execute("SELECT name FROM sqlite_master WHERE type='table'") # (3)
    print(result.fetchall()) # (3)
\
if __name__ == "__main__": # (4)
    init_db()

1. We maken een verbinding met hetzelfde database bestand.
2. Net als het SQLite bestand verwachten we dat schema.sql in dezelfde directory staat als de db.py module zelf. Met open en read lezen we dat bestand in en voeren het uit als een script in de database, met de functie executescript.
3. Achteraf controleren we welke tables effectief bestaan.
4. Deze code zal enkel worden uitgevoerd als we het db.py bestand rechtstreeks uitvoeren, niet als het gewoon geïmporteerd wordt.

Deze code moeten we één maal uitvoeren zodat de database klaar is voor gebruik.

1
2
3

$ uv run python flaskr/db.py
SQLite schema created. Tables in DB:
[('sqlite_sequence',), ('user',), ('post',)]

Registreren met de Applicatie¶

We willen dat de close_db functie uit de db.py module uitgevoerd wordt op het einde van elke request.

We passen de factory functie als volgt aan:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

from flask import Flask
from . import db # (1)

def create_app() -> Flask:
    app = Flask(__name__)
    app.secret_key = "dev"
    app.jinja_options["autoescape"] = True

    @app.route("/ping")
    def ping():
        return "pong"

    app.teardown_appcontext(db.close_db) # (2)

    return app

1. De `db module moet natuurlijk geïmporteerd worden.
2. teardown_appcontext registreert functies die uitgevoerd moeten worden als de "Application Context" (g object) verwijderd wordt (op het einde van elke request dus).

Blueprints en Views¶

Een eerste Blueprint¶

Een view is een functie die bepaalt wat er gebeurt en teruggestuurd wordt voor een bepaalde route.

Een blueprint is een manier om een groep relateerde views te organiseren. De flaskr applicatie zal twee blueprints gebruiken: een voor authenticatie en een voor blogposts.

We starten met de basis voor authenticatie. Om de code gestructureerd en georganiseerd te houden werken we opnieuw in een aparte module.

1
2
3

from flask import Blueprint

bp = Blueprint("auth", __name__, url_prefix="/auth")

De Blueprint heeft:

1. Een vrij te kiezen naam, hier gewoon auth
2. De naam van de package of module waartoe de Blueprint behoort. Net zoals voor de Flask app gebruiken we __name__ (dus uiteindelijk flaskr)
3. Een url_prefix die voor het pad van elke view route wordt geplaatst om zo het volledige pad van die route te bepalen.

In de factory gebruiken we de app.register_blueprint functie om het Blueprint object toe te voegen aan de applicatie.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Bestaande imports
from . import auth, db


def create_app() -> Flask:
    # Bestaande code

    app.register_blueprint(auth.bp)

    return app

Eerste Auth View: register¶

Als een gebruiker de /auth/register pagina bezoekt (GET) moet deze view HTML terugsturen met een form die de username en password velden bevat. Bij het verzenden van de form (POST) moet de view beide velden valideren, een nieuwe gebruiker opslaan en doorsturen naar de login pagina.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

from flask import (
    Blueprint,
    flash,
    g,
    redirect,
    render_template,
    request,
    session,
    url_for,
)
from werkzeug.security import check_password_hash, generate_password_hash

from flaskr.db import get_db

bp = Blueprint("auth", __name__, url_prefix="/auth")


@bp.route("/register", methods=("GET", "POST")) # (1)
def register():
    if request.method == "POST":                # (2)
        username = request.form["username"]     # (2)
        password = request.form["password"]     # (2)
        error = None

        if not username:                        # (3)
            error = "Username is required."     # (3)
        elif not password:                      # (3)
            error = "Password is required."     # (3)

        if error is None:
            db = get_db()                           # (4)
            try:
                db.execute(                                                # (5)
                    "INSERT INTO user (username, password) VALUES (?, ?)", # (5)
                    (username, generate_password_hash(password)),          # (6)
                )                                                          # (5)
                db.commit()                                                # (5)
            except db.IntegrityError:                                      # (7)
                error = f"User {username} is already registered."          # (7)
            else:
                return redirect(url_for("auth.login"))                     # (8)

        flash(error)                                                       # (9)

    return render_template("auth/register.html.j2")                        # (10)

1. Een view aan een blueprint route koppelen werkt op precies delfde manier als rechtstreeks in de app. I.p.v. app.route gebruiken we bp.route.
2. Het request object gebruiken om de HTTP method en form te bekijken kennen we al.
3. Zowel de username als het password mogen uiteraard niet leeg zijn.
4. De get_db functie uit onze eigen db module geeft een Connection object om met de database te werken.
5. Met de Connection.execute kunnen we standaard SQL commando's naar de database sturen. Een commit naar de database moet expliciet gebeuren via de commit functie.
6. Het password bewaren we natuurlijk niet in zijn oorspronkelijke vorm. Met de generate_password_hash functie uit de werkzeug package verkrijgen we een hash van het password.
7. Als er reeds een database row bestaat met dezelfde username zal de execute functie een IntegrityError exception geven (dankzij de UNIQUE constraint in het schema). In dat geval bereiden we een verklarende foutmelding voor.
8. Als alles is gelukt sturen we de gebruiker door naar de login pagina. "auth.login" slaat op de login view in the auth blueprint en die moeten we natuurlijk nog maken.
9. Met de flask.flash functie kunnen we een string registreren die we later in de template zullen gebruiken om de aandacht van de gebruiker te trekken.
10. We gebruiken een template (deze bekijken we in het volgende hoofdstuk) om de registratiepagina terug te sturen. Dit gebeurt in twee scenarios:
    1. De gebruiker bezocht de pagina rechtstreeks en moet de form dus nog invullen (request.method == "GET")
    2. Er was een fout or probleem bij het verwerken van de form (POST)

Wat gebeurt er als we nu al de pagina http://127.0.0.1:5000/auth/register proberen te bezoeken?

Testen met eenvoudige Template¶

Om deze eerste route te kunnen uitproberen voegen we een eenvoudige tijdelijke template toe:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

<!doctype html>
<html>
<body>
  <h1>Register</h1>
  <p style="color:red; font-weight: bold;">
    {% for message in get_flashed_messages() %} # (1)
    {{ message }}
    {% endfor %}
  </p>

  <form method="post"> # (2)
    <label for="username">Username</label>
    <input name="username" id="username" required>
    <label for="password">Password</label>
    <input type="password" name="password" id="password" required>
    <input type="submit" value="Register"> # (2)
  </form>
</body>
</html>

1. De get_flashed_messages() functie geeft een lijst terug met alle berichten (strings) waarmee de flash uitgevoerd werd tijdens deze request. Op die manier kunnen we (optioneel) problemen uit de laatste POST melden aan de gebruiker.
2. Een typische login form, met velden voor username en password wordt gepresenteerd.

We kunnen nu in principe de route al voor een deel uittesten.

1

flask --app flaskr run --debug

Via http://127.0.0.1:5000/auth/register kunnen we nu een gebruiker registreren. Als we 2x dezelfde username proberen registreren moeten we een foutmelding krijgen.

Tweede Auth View: login¶

Nadat een gebruiker geregistreerd is moet deze natuurlijk kunnen inloggen.

Oefening¶

Probeer zelf als oefening (in groepen) de view functie te schrijven.

De login view volgt dezelfde structuur als de register view:

• Een GET request geeft een login form terug
• De ingevulde login form wordt gePOST
• De form velden worden gevalideerd en dit bepaalt de response
  • Fout: zelfde pagina en toon foutmelding
  • Juist: user_id uit database opslaan in cookie ; doorsturen naar index pagina

- Met `db.execute("SQL QUERY TEXT").fetchone()` krijg je de eerst rij van het resultaat van de query, of `None`.
- Met [`check_password_hash(hash, password) -> bool`](https://werkzeug.palletsprojects.com/en/stable/utils/#werkzeug.security.check_password_hash) kan je controleren of `hash` de hash is die hoort bij `password`.
- Start eenvoudig en voeg stap voor stap functionaliteit toe.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

<!doctype html>
<html>
<body>
  <h1>Login</h1>
  <p style="color:red; font-weight: bold;">
    {% for message in get_flashed_messages() %} # (1)
    {{ message }}
    {% endfor %}
  </p>

  <form method="post"> # (2)
    <label for="username">Username</label>
    <input name="username" id="username" required>
    <label for="password">Password</label>
    <input type="password" name="password" id="password" required>
    <input type="submit" value="Login"> # (2)
  </form>
</body>
</html>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Bestaande code

@bp.route("/login", methods=("GET", "POST"))
def login():
    if request.method == "POST":
        username = request.form["username"]
        password = request.form["password"]
        db = get_db()
        error = None
        user_row = db.execute(                                        # (1)
            "SELECT * FROM user WHERE username = ?", (username,)      # (1)
        ).fetchone()                                                  # (1)

        if user_row is None:                                          # (2)
            error = "Incorrect username."                             # (2)
        elif not check_password_hash(user_row["password"], password): # (3)
            error = "Incorrect password."

        if error is None:
            session.clear()                                           # (4)
            session["user_id"] = user_row["id"]                       # (4)
            return redirect(url_for("blog.index"))                    # (4)

        flash(error)

    return render_template("auth/login.html.j2")

User automatisch laden¶

We willen dus eigenlijk dat voor elke request gecontroleerd wordt of een user_id in de meegestuurde cookie staat. Bovendien zou het handig zijn om direct de details van die user op te halen uit de database. Flask heeft hiervoor een handige functie die we hieronder bekijken. Deze code voegen we toe in auth.py.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Bestaande code

@bp.before_app_request                # (1)
def load_logged_in_user():
    user_id = session.get('user_id')

    if user_id is None:               # (2)
        g.user = None                 # (2)
    else:
        g.user = get_db().execute(                        # (3)
            'SELECT * FROM user WHERE id = ?', (user_id,) # (3)
        ).fetchone()                                      # (3)

1. before_app_request is net zoals route een decorator maar i.p.v. een gewone view functie die enkel bij een bepaald route (URL pad) hoort zal deze functie voor elke request worden uitgevoerd. En dit, vóór dat de eigenlijke view functie wordt uitgevoerd.
2. We gaan the de flask.g proxy (uit les 1 - de request context) gebruiken om de details van de user op de slaan. Op dit manier zullen ze beschikbaar zijn voor de volledige request. Als er geen user_id te vinden is in de session kunnen we ook niets ophalen uit de database en initialiseren we g.user met None. Dit wordt later dan ook de aanduiding dat de gebruiker nog moet inloggen.
3. Als er wél een user_id is gebruiken we deze om de volledige row van die user op te zoeken en bewaren het resultaat in g.user.

Om nu te controleren of een request wel van een ingelogde gebruiker komt (een geautoriseerde request) moeten we gewoon controleren of g.user iets bevat (dus niet None is). Hiervoor maken we zelf een nieuwe decorator die we dan kunnen toevoegen aan specifieke toekomstige view functies die enkel toegankelijk zijn voor ingelogde gebruikers. Hoe decorators, en specifiek zelfgemaakte decorators, precies werken komt aan bod in de module Python Architectuur.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import functools
# Bestaande code

def login_required(view): # (1)
    @functools.wraps(view)
    def wrapped_view(**kwargs):
        if g.user is None:                         # (2)
            return redirect(url_for("auth.login")) # (2)

        return view(**kwargs) # (3)

    return wrapped_view

1. We maken een eigen login_required decorator. Die zullen we kunnen gebruiken met @login_required boven bepaalde view functies.
2. Als er geen g.user data is sturen we de request direct door naar de login pagina. Verder gebeurt er niets in deze decorator.
3. Anders wordt de gedecoreerde functie gewoon uitgevoerd.

Uitloggen¶

Om een gebruiker uit te loggen moeten we dan eenvoudigweg de informatie opgeslagen in de cookie verwijderen.

1
2
3
4
5
6

# Bestaande code

@bp.route('/logout')
def logout():
    session.clear()
    return redirect(url_for('blog.index'))

Templates¶

In dit hoofdstuk bekijken we de verschillende Jinja2 templates die we nodig hebben in de views van the auth module uit het vorig deel:

• auth/register.html.j2
• auth/login.html.j2

De Base Layout¶

Elke pagina zal een aantal identieke basis-elementen bevatten. I.p.v. deze in elke template te herhalen kunnen we template inheritance gebruiken en eenzelfde template als basis maken voor alle andere templates.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<!doctype html>
<title>{% block title %}{% endblock %} - Flaskr</title>                       # (1)
<link rel="stylesheet" href="{{ url_for('static', filename='style.css') }}">  # (2)
<nav>                                                                         # (3)
  <h1>Flaskr</h1>
  <ul>
    {% if g.user %}                                                           # (4)
    <li><span>{{ g.user['username'] }}</span>
    <li><a href="{{ url_for('auth.logout') }}">Log Out</a>
    {% else %}
    <li><a href="{{ url_for('auth.register') }}">Register</a>
    <li><a href="{{ url_for('auth.login') }}">Log In</a>
    {% endif %}                                                               # (4)
  </ul>
</nav>
<section class="content">
  <header>
    {% block header %}{% endblock %}
  </header>
  {% for message in get_flashed_messages() %}  # (5)
  <div class="flash">{{ message }}</div>       # (5)
  {% endfor %}                                 # (5)
  {% block content %}{% endblock %}
</section>

1. De title, header en content blocks blijven hier leeg en zullen worden ingevuld in de individuele templates. Het zijn hier dus louter placeholders.
2. De url_for functie is automatisch beschikbaar in templates.
3. Bovenaan de pagina willen we navigatie-elementen
4. Ook het flask.g object is automatisch beschikbaar. Hier kunnen we direct de user details uit het vorige hoofdstuk gebruiken: als de gebruiker ingelogd is tonen we zijn username en een link naar de logout pagina. Zo niet, dan tonen we links naar de register and login pagina's.
5. Met de get_flashed_messages functie krijgen we een lijst met alle strings die in the view functies met de flash functie zijn aangemaakt.

De Register Template¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{% extends 'base.html.j2' %} # (1)

{% block header %} # (2)
<h1>{% block title %}Register{% endblock %}</h1> # (2)
{% endblock %} # (2)

{% block content %}
<form method="post"> # (3)
  <label for="username">Username</label>
  <input name="username" id="username" required>
  <label for="password">Password</label>
  <input type="password" name="password" id="password" required>
  <input type="submit" value="Register">
</form> # (3)
{% endblock %}

1. Alle individuele templates zullen de base template uitbreiden
2. Op deze manier overschrijven we de (initieel lege) header en template blokken uit de base template. The inhoud zal komen te staan op de plaats van deze blokken in de base template.
3. Voor de register pagina tonen we een eenvoudige form waar een username en password worden ingevuld.

De Login Template¶

De login template is eigenlijk identiek aan de register template. Alleen de title en de submit knop verschillen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{% extends 'base.html.j2' %}

{% block header %}
<h1>{% block title %}Log In{% endblock %}</h1>
{% endblock %}

{% block content %}
<form method="post">
  <label for="username">Username</label>
  <input name="username" id="username" required>
  <label for="password">Password</label>
  <input type="password" name="password" id="password" required>
  <input type="submit" value="Log In">
</form>
{% endblock %}

Een Eerste Test¶

Met de uitgewerkte auth views en templates moeten we al in staat zijn een user aan te registreren en in te loggen.

flask --app flaskr run --debug

• Ga naar http://127.0.0.1:5000/auth/register en geef een username and password in.
• Je wordt automatisch doorgestuurd naar http://127.0.0.1:5000/auth/login.
• Log in met dezelfde gegevens.
• Je krijgt een fout omdat de index view nog niet bestaat

Een SQLite database bestand is aangemaakt in instance/flaskr.sqlite. Met de sqlite3 CLI kunnen we de database bekijken. Kijk op https://sqlite.org/index.html hoe je dit kan installeren voor jou systeem.

$ sqlite3 instance/flaskr.sqlite
SQLite version 3.45.3 2024-04-15 13:34:05
Enter ".help" for usage hints.

sqlite> .schema
CREATE TABLE user (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  username TEXT UNIQUE NOT NULL,
  password TEXT NOT NULL
);
CREATE TABLE sqlite_sequence(name,seq);
CREATE TABLE post (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  author_id INTEGER NOT NULL,
  created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  title TEXT NOT NULL,
  body TEXT NOT NULL,
  FOREIGN KEY (author_id) REFERENCES user (id)
);

sqlite> select * from user;
1|fdevaux|scrypt:32768:8:1$nDOqwkuk4IMOTlIS$b4c25d6577cd213c2963f31aba0591cffa3d878e6b4af0da5a459410a131583a15c103810dc51020a0abdd3bdc0fbbe66dbfea3bbd6fecc6bc116c270da81689

Static Files¶

Met CSS zorgen we dat de pagina's er iets beter uitzien. Het CSS bestand is statisch, want het is hetzelfde voor elke request. Daarom plaatsen we het in een flaskr/static directory (i.p.v. flaskr/templates). Met de functie url_for('static', filename='style.css') kunnen we de juiste URL naar het bestand genereren. Dit hebben we al gebruikt in de base.html.j2 template.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

html { font-family: sans-serif; background: #eee; padding: 1rem; }
body { max-width: 960px; margin: 0 auto; background: white; }
h1 { font-family: serif; color: #377ba8; margin: 1rem 0; }
a { color: #377ba8; }
hr { border: none; border-top: 1px solid lightgray; }
nav { background: lightgray; display: flex; align-items: center; padding: 0 0.5rem; }
nav h1 { flex: auto; margin: 0; }
nav h1 a { text-decoration: none; padding: 0.25rem 0.5rem; }
nav ul  { display: flex; list-style: none; margin: 0; padding: 0; }
nav ul li a, nav ul li span, header .action { display: block; padding: 0.5rem; }
.content { padding: 0 1rem 1rem; }
.content > header { border-bottom: 1px solid lightgray; display: flex; align-items: flex-end; }
.content > header h1 { flex: auto; margin: 1rem 0 0.25rem 0; }
.flash { margin: 1em 0; padding: 1em; background: #cae6f6; border: 1px solid #377ba8; }
.post > header { display: flex; align-items: flex-end; font-size: 0.85em; }
.post > header > div:first-of-type { flex: auto; }
.post > header h1 { font-size: 1.5em; margin-bottom: 0; }
.post .about { color: slategray; font-style: italic; }
.post .body { white-space: pre-line; }
.content:last-child { margin-bottom: 0; }
.content form { margin: 1em 0; display: flex; flex-direction: column; }
.content label { font-weight: bold; margin-bottom: 0.5em; }
.content input, .content textarea { margin-bottom: 1em; }
.content textarea { min-height: 12em; resize: vertical; }
input.danger { color: #cc2f2e; }
input[type=submit] { align-self: start; min-width: 10em; }

Als je nu http://127.0.0.1:5000/auth/login bekijkt zou het er (iets) beter moeten uitzien.

De Blog Blueprint¶

Blueprint Basis¶

In auth.py hebben we een Blueprint gemaakt voor alle authenticatie views. Op dezelfde manier maken we nu een nieuwe blog.py module met een Blueprint voor alle blog views.

Uiteindelijk zullen we volgende views nodig hebben:

1. Index, om alle blogposts van alle gebruikers te laten zien.
2. Create, om een ingelogde gebruiker een nieuwe post te laten schrijven.
3. Update, om een ingelogde gebruiker een bestaande post te laten aanpassen of verwijderen.

We starten met enkel het Blueprint object en de nodige imports.

1
2
3
4
5
6
7

from flask import Blueprint, flash, g, redirect, render_template, request, url_for
from werkzeug.exceptions import abort

from flaskr.auth import login_required # (1)
from flaskr.db import get_db           # (2)

bp = Blueprint("blog", __name__)       # (3)

1. Onze eigen login_required decorator zullen we nodig hebben voor de views waarmee een blogpost bewerkt wordt.
2. Ook get_db hebben we opnieuw nodig, ditmaal om blogpost naar de database weg te schrijven en terug op te halen.
3. In tegenstelling tot de auth Blueprint geven we hier geen url_prefix argument mee. Hierdoor komen alle routes voor deze Blueprint in de 'root' van de URL terug (bvb. http://127.0.0.1:5000/create).

Ook deze Blueprint moeten we in de app registreren:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Bestaande imports
from . import auth, blog, db


def create_app() -> Flask:
    # Bestaande code

    app.register_blueprint(blog.bp)

    return app

De Index View¶

De index pagina zal alle blogpost laten zien, van nieuw naar oud.

1
2
3
4
5
6
7
8
9

@bp.route("/") # (1)
def index():
    db = get_db()
    posts = db.execute( # (2)
        "SELECT p.id, title, body, created, author_id, username "
        "FROM post p JOIN user u ON p.author_id = u.id "
        "ORDER BY created DESC" # (2)
    ).fetchall() # (3)
    return render_template("blog/index.html.j2", posts=posts) # (4)

1. Door enkel / in het pad van de route te gebruiken wordt deze toegankelijke als http://127.0.0.1:5000.
2. Met een JOIN tussen beide tables halen we de informatie op van elke post maar ook van de auteur van de post.
3. Met de fetchall functie krijgen we een lijst van alle rows. Elk item in die lijst stelt 1 row voor, maar krijgen we opnieuw als een dictionary.
4. Door die lijst (posts) mee te geven in de render_template functie zullen we deze kunnen gebruiken in de template.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{% extends 'base.html.j2' %}

{% block header %}
<h1>{% block title %}Posts{% endblock %}</h1>
{% if g.user %} # (1)
<a class="action" href="{{ url_for('blog.create') }}">New</a>
{% endif %} # (1)
{% endblock %}

{% block content %}
{% for post in posts %} # (2)
<article class="post">
  <header>
    <div>
      <h1>{{ post['title'] }}</h1> # (3)
      <div class="about">by {{ post['username'] }} on {{ post['created'] }}</div>
    </div>
    {% if g.user['id'] == post['author_id'] %} # (4)
    <a class="action" href="{{ url_for('blog.update', id=post['id']) }}">Edit</a>
    {% endif %} # (4)
  </header>
  <p class="body">{{ post['body'] }}</p>
</article>
{% if not loop.last %}
<hr>
{% endif %}
{% endfor %}
{% endblock %}

1. Voor ingelogde gebruikers (m.a.w. als g.user niet None is) voegen we een extra link toe naar de (toekomstige) pagina om een nieuwe post te maken.
2. Voor de inhoud van de pagina itereren we over de lijst van posts die wordt meegegeven aan de template. De post variable zal dus telkens een dictionary zijn met alle velden uit de database query.
3. Zo is post['title'] bijvoorbeeld de titel van één post en gebruiken we dit voor de H1 header.
4. Als de ID van de auteur van een post hetzelfde is als de ID van de ingelogde gebruiker dan voegen we (voor die specifieke post) een link toe naar de pagina om een post aan te passen. In de url_for functie kunnen extra argumenten toegevoegd worden die als parameters zullen worden meegestuurd. Hier geven we de ID van de post mee zodat de blog.update view de juiste post kan laten bewerken.

De Create View¶

Deze view moet opnieuw zowel GET als POST methodes ondersteunen. Bij een GET wordt een form weergegeven met alle nodige velden om een nieuw post de schrijven. Bij een POST wordt de form data gevalideerd en in de database opgeslagen. Bij success wordt er ook hier geredirect naar de index pagina.

Probeer zelf als oefening (in groepen) de template en view functie te schrijven.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

@bp.route("/create", methods=("GET", "POST"))
@login_required # (1)
def create():
    if request.method == "POST":
        title = request.form["title"]
        body = request.form["body"]
        error = None

        if not title:
            error = "Title is required."

        if error is not None:
            flash(error)
        else:
            db = get_db()
            db.execute(
                "INSERT INTO post (title, body, author_id) VALUES (?, ?, ?)", # (2)
                (title, body, g.user["id"]),                                  # (2)
            )
            db.commit()
            return redirect(url_for("blog.index"))

    return render_template("blog/create.html.j2")

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{% extends 'base.html.j2' %}

{% block header %}
<h1>{% block title %}New Post{% endblock %}</h1>
{% endblock %}

{% block content %}
<form method="post">
  <label for="title">Title</label>
  <input name="title" id="title" value="{{ request.form['title'] }}" required>
  <label for="body">Body</label>
  <textarea name="body" id="body">{{ request.form['body'] }}</textarea>
  <input type="submit" value="Save">
</form>
{% endblock %}

Tussendoor Testen¶

Het is altijd aan te raden nieuwe code te testen van zodra dat mogelijk is. Hoe meer nieuwe code je schrijft tussen twee testen, hoe moeilijker het kan zijn een fout te debuggen.

We zouden nu in staat moeten zijn een post te schrijven en vervolgende de bestaande post(s) te bekijken.

• Als we als ingelogde gebruiker http://127.0.0.1:5000 bezoeken zien we natuurlijk nog geen posts, maar wel een nieuwe New link.
• Via die link komen we op http://127.0.0.1:5000/create waar we een post kunnen schrijven en opslaan.
• We worden terug doorgestuurd naar http://127.0.0.1:5000 maar hier krijgen we een fout ... omdat de blog.update view nog niet bestaat. Geen probleem dus. Als we uitloggen zouden we de post wel moeten zien (waarom?)

De Update View¶

Voor zowel de update als de delete views moet een post uit de database worden opgehaald (op basis van een post ID). Er moet ook gecontroleerd worden dat de ingelogde gebruiker wel degelijk de auteur is van de post.

We maken een aparte functie voor deze gemeenschappelijke functionaliteit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

def get_post(id: int) -> dict:
    post = (
        get_db()
        .execute( # (1)
            "SELECT p.id, title, body, created, author_id, username"
            " FROM post p JOIN user u ON p.author_id = u.id"
            " WHERE p.id = ?",
            (id,),
        )
        .fetchone() # (1)
    )

    if post is None: # (2)
        abort(404, f"Post id {id} doesn't exist.")

    if post["author_id"] != g.user["id"]:
        abort(403) # (2)

    return post

1. We gebruiken de gegeven id om een post uit de post table op te halen.
2. De id moet natuurlijk bestaan. De author_id van de post moet kloppen met de id van de ingelogde gebruiker. Als dit niet het geval is moet een fout worden teruggestuurd. Hiervoor gebruiken we de flask.abort functie. Deze stop verdere afhandeling van de request en stuurt een response terug met de aangegeven status code. Zijn 404 en 403 goede codes in dit geval?

Met behulp van deze functie kunnen we nu de update view schrijven. Die lijkt natuurlijk erg op de create view.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@bp.route("/<int:id>/update", methods=("GET", "POST")) # (1)
@login_required
def update(id):
    post = get_post(id)

    if request.method == "POST":
        title = request.form["title"]
        body = request.form["body"]
        error = None

        if not title:
            error = "Title is required."

        if error is not None:
            flash(error)
        else:
            db = get_db()
            db.execute(
                "UPDATE post SET title = ?, body = ? WHERE id = ?", (title, body, id) # (2)
            )
            db.commit()
            return redirect(url_for("blog.index"))

    return render_template("blog/update.html.j2", post=post) # (3)

1. De ID van de post maakt deel uit van het pad van de route (bvb. /123/update).
2. I.p.v. INSERT gebruiken we UPDATE om een bestaande database row aan te passen
3. De details van de bestaande post worden meegeven aan de template zodat de post kan worden weergegeven in de pagina.

Ook deze template toont een eenvoudige form met velden voor de post informatie.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

{% extends 'base.html.j2' %}

{% block header %}
<h1>{% block title %}Edit "{{ post['title'] }}"{% endblock %}</h1>
{% endblock %}

{% block content %}
<form method="post">
  <label for="title">Title</label>
  <input name="title" id="title" value="{{ request.form['title'] or post['title'] }}" required> # (1)
  <label for="body">Body</label>
  <textarea name="body" id="body">{{ request.form['body'] or post['body'] }}</textarea> # (1)
  <input type="submit" value="Save">
</form>
<hr>
<form action="{{ url_for('blog.delete', id=post['id']) }}" method="post">
  <input class="danger" type="submit" value="Delete" onclick="return confirm('Are you sure?');">
</form>
{% endblock %}

1. Voor de title en body input velden van de form wordt in principe de informatie van de huidige post al ingevuld (bvb. post['title']). Maar als er een fout optreedt bij het verwerken van de POST komt de gebruiker op dezelfde pagina terug. In dit geval willen we de informatie uit de geposte form behouden (bvb. request.form['body'])

De Delete View¶

De delete view heeft geen template nodig. De delete knop in de update template POST naar de route van de delete view (/<post_id>/delete). De delete view stuurt de gebruiker gewoon terug naar de index pagina.

1
2
3
4
5
6
7
8

@bp.route("/<int:id>/delete", methods=("POST",))
@login_required
def delete(id):
    get_post(id)
    db = get_db()
    db.execute("DELETE FROM post WHERE id = ?", (id,))
    db.commit()
    return redirect(url_for("blog.index"))

Klaar!¶

De applicatie is klaar. Test zelf de verschillende functies uit. Controleer bijvoorbeeld dat elke gebruiker enkel zijn eigen posts kan bewerken. Probeer ook wat er gebeurt als je dit probeert te omzeilen.

Testen¶

Je applicatie handmatig uittesten is leuk maar het wordt snel problematisch als je voor elke toekomstige aanpassing alle bestaande functionaliteit met de hand moet controleren.

Gelukkig voorziet Flask een aantal handige tools om eenvoudig je applicatie functioneel te testen.

Eerste Stappen¶

Pytest¶

Om testen uit te voeren gebruiken we pytest.

uv add pytest

conda install pytest

Flask TestClient¶

De functie app.test_client() geeft een flask.testing.FlaskClient object terug.

Met dit object kan je gemakkelijk verschillende test requests sturen naar het app object, zonder een browser of andere externe tools te moeten gebruiken.

Bijvoorbeeld:

1
2
3
4
5
6
7
8

from flaskr import create_app

def test_register_get():
    app = create_app()
    client = app.test_client()
    response = client.get("/auth/register")

    assert response.status_code == 200

$ pytest tests/test_auth.py
============================== test session starts ==============================
platform darwin -- Python 3.13.5, pytest-8.4.2, pluggy-1.6.0
rootdir: /Users/dfabrice/dev/github/flaskr
configfile: pyproject.toml
collected 1 item

tests/test_auth.py .                                                      [100%]

=============================== 1 passed in 0.08s ===============================

ImportError while loading conftest '.../flaskr/tests/test_auth.py'.
tests/conftest.py:4: in <module>
    from flaskr import create_app
E   ModuleNotFoundError: No module named 'flaskr'

[tool.pytest.ini_options]
pythonpath = ["."]

Test Database¶

De vorige test is op zich veilig, omdat het om een eenvoudige GET request gaat die geen wijzigingen uitvoert. Maar wat als we registratie volledige willen testen? Of het maken van nieuwe posts.

Een van de mogelijke oplossing hiervoor is om tijdens de testen een 'in-memory' SQLite database te gebruiken. Hierbij bewaart SQLite alles enkel in het geheugen. Dit doen we door aan sqlite3.connect de string :memory: mee te geven (i.p.v. de naam van een bestand).

Een goed moment om onze create_app factory configureerbaar te maken:

1
2
3
4
5

def create_app(database: str = db.SQLITE_DB_FILE) -> Flask: # (1)
    app = Flask(__name__)
    app.config["DATABASE"] = database # (2)

    # Bestaande code

1. create_app heeft nu een optionele database parameter. Als default behouden we gewoon "flaskr.sqlite".
2. De waarde van die parameter slaan we op onder de zelfgekozen "DATABASE" key in de config dictionary van het Flask app object.

In de get_db functie van de db.py module moeten we dan ook die zelfde configuratie gebruiken om een verbinding met de database te maken:

1
2
3
4
5
6
7

from flask import current_app, g # (1)

def get_db() -> sqlite3.Connection:
    if "db" not in g:
        g.db = sqlite3.connect(current_app.config["DATABASE"]) # (2)
        g.db.row_factory = sqlite3.Row
    return g.db

1. current_app geeft altijd het huidige Flask app object terug.
2. Op die manier krijgen we via current_app.config["DATABASE"] de geconfigureerde database naam.

Nu kunnen we op een veilige manier een test toevoegen voor de POST method:

1
2
3
4
5
6

def test_register_post():
   app = create_app(":memory:")
   client = app.test_client()
   response = client.post("/auth/register", data={"username": "a", "password": "a"})

   assert response.status_code == 302

Helaas werkt het nog niet helemaal en krijgen we de volgende fout:

  File "./dev/github/flaskr/flaskr/auth.py", line 35, in register
    db.execute(
    ~~~~~~~~~~^
        "INSERT INTO user (username, password) VALUES (?, ?)",
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        (username, generate_password_hash(password)),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
sqlite3.OperationalError: no such table: user
============================ short test summary info =============================
FAILED tests/test_auth.py::test_register_post - assert 500 == 302
=============================== 1 failed in 0.21s ================================

Wat is het probleem?

De database (in-memory!) is nooit geïnitialiseerd en heeft dus geen tables!

In de db module hebben we een functie die precies dat doet, init_db. We kunnen deze op dezelfde manier configureerbaar maken en gebruiken tijdens het opstellen van de test:

1
2
3
4

def init_db(database: str = SQLITE_DB_FILE):
    db = sqlite3.connect(database)

    # Bestaande code

1
2
3
4
5
6
7
8
9

from flaskr import create_app, db

def test_register_post():
    app = create_app(":memory:")
    db init_db(":memory:")
    client = app.test_client()
    response = client.post("/auth/register", data={"username": "a", "password": "a"})

    assert response.status_code == 302

Nog steeds krijgen we dezelfde fout: sqlite3.OperationalError: no such table: user! De reden is nu niet zo triviaal.

In-Memory SQLite Valkuil¶

De in-memory SQLite Connection die onze test gebruikt heeft een bijzonderheid. Als we in de Python SQLite documentatie snuisteren komen we uit op SQLite In Memory Databases, en daar lezen we dit:

Every :memory: database is distinct from every other. So, opening two database connections each with the filename ":memory:" will create two independent in-memory databases

En even verder:

In-memory databases are allowed to use shared cache if they are opened using a URI filename. rc = sqlite3_open("file::memory:?cache=shared", &db);

Terug in de Python documentatie vinden we zelfs een voorbeeld: db = "file:mem1?mode=memory&cache=shared". We zien daar ook dat bij de sqlite3.connect functie het argument uri=True gebruikt moet worden. Dit moeten we dus ook aanpassen zowel in get_db als in init_db in onze db.py module.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

def get_db() -> sqlite3.Connection:
    print(f"GET DB WITH {current_app.config['DATABASE']}")
    if "db" not in g:
        g.db = sqlite3.connect(current_app.config["DATABASE"], uri=True)
        g.db.row_factory = sqlite3.Row
    return g.db


def close_db(_exc=None):
    if "db" in g:
        g.db.close()

def init_db(database: str = SQLITE_DB_FILE):
    print(f"INIT DB WITH {database}")
    db = sqlite3.connect(database, uri=True)

    with open(LOCAL_DIRECTORY / "schema.sql") as schema:
        db.executescript(schema.read())

    print("SQLite schema created. Tables in DB:")
    result = db.execute("SELECT name FROM sqlite_master WHERE type='table'")
    print(result.fetchall())

We passen onze test opnieuw aan. We controleren ook direct of we wel worden doorgestuurd (redirect) naar de login pagina.

1
2
3
4
5
6
7
8

def test_register_post():
    app = create_app("file:mem1?mode=memory&cache=shared")
    db.init_db("file:mem1?mode=memory&cache=shared")
    client = app.test_client()
    response = client.post("/auth/register", data={"username": "a", "password": "a"})

    assert response.status_code == 302
    assert response.headers["Location"] == "/auth/login"

De test werkt nu eindelijk!

User controleren in de database¶

Na een registratie zouden we ook graag controleren dat de nieuwe gebruiker ook daadwerkelijk is aangemaakt in de database. We voegen een extra assert toe op het einde van de test:

1
2
3
4
5
6
7

def test_register_post():
    # Bestaande code

    assert (
        db.get_db().execute("SELECT * FROM user WHERE username = 'a'").fetchone()
        is not None
    )

We krijgen echter een nieuwe fout ...

        assert (
>           db.get_db().execute("SELECT * FROM user WHERE username = 'a'").fetchone()
            ^^^^^^^^^^^
            is not None
        )

tests/test_auth.py:23:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
flaskr/db.py:8: in get_db
    if "db" not in g:
       ^^^^^^^^^^^^^
.venv/lib/python3.13/site-packages/werkzeug/local.py:318: in __get__
    obj = instance._get_current_object()
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def _get_current_object() -> T:
        try:
            obj = local.get()
        except LookupError:
>           raise RuntimeError(unbound_message) from None
E           RuntimeError: Working outside of application context.
E
E           This typically means that you attempted to use functionality that needed
E           the current application. To solve this, set up an application context
E           with app.app_context(). See the documentation for more information.

.venv/lib/python3.13/site-packages/werkzeug/local.py:519: RuntimeError

Om deze fout beter te begrijpen blikken we even terug op Les 1 - De Application Context, ofwel op de Flask Application Context documentatie pagina.

get_db inspecteert het flask.g object. En dat object bestaat enkel binnen een application context. Verder lezen we ook dit:

Flask automatically pushes an application context when handling a request.

Maar op het moment dat we hier get_db uitvoeren zitten we niet 'in een request'. Verder lezen we ook:

If you try to access current_app, or anything that uses it, outside an application context, you’ll get this error message:

RuntimeError: Working outside of application context.

This typically means that you attempted to use functionality that
needed to interface with the current application object in some way.
To solve this, set up an application context with app.app_context().

Onze test wordt dus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

def test_register_post():
    app = create_app("file:mem1?mode=memory&cache=shared")
    db.init_db("file:mem1?mode=memory&cache=shared")
    client = app.test_client()
    response = client.post("/auth/register", data={"username": "a", "password": "a"})

    assert response.status_code == 302
    assert response.headers["Location"] == "/auth/login"

    with app.app_context():
        assert (
            db.get_db().execute("SELECT * FROM user WHERE username = 'a'").fetchone()
            is not None
        )

Pytest Fixtures¶

Een van de beste features in pytest is fixtures.

Met fixtures kunnen data of objecten die in verschillende testen gebruikt worden eenmalig gedefinieerd worden. Vervolgens kan elke test die een fixture nodig heeft deze verkrijgen door simpelweg de naam de de fixture functie in de argumenten van de test-functie te plaatsen.

Als we naar onze eerste twee testen kijken zien we dat ze beiden een test client (FlaskClient) nodig hebben om test requests te versturen. Een prima kandidaat voor een fixture dus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

import pytest # (1)
from flask import Flask
from flask.testing import FlaskClient # (1)

from flaskr import create_app, db

@pytest.fixture # (2)
def app():
    database = "file:mem1?mode=memory&cache=shared"
    app = create_app(database)
    db.init_db(database)
    return app # (2)

@pytest.fixture # (3)
def client(app: Flask):
    return app.test_client() # (3)

def test_register_get(client: FlaskClient): # (4)
    response = client.get("/auth/register")

    assert response.status_code == 200

def test_register_post(app: Flask, client: FlaskClient): # (5)
    response = client.post("/auth/register", data={"username": "a", "password": "a"})

    assert response.status_code == 302
    assert response.headers["Location"] == "/auth/login"

    with app.app_context():
        assert (
            db.get_db().execute("SELECT * FROM user WHERE username = 'a'").fetchone()
            is not None
        )