Exercise 1: A Real, Protected Delete Route — Possible Solution ==================================================================== THE ROUTE ------------------------------ def delete_note_post(request): note_id = request.params['id'] conn.execute('DELETE FROM notes WHERE id = ?', (note_id,)) conn.commit() return Response.redirect('/') app.add_route('POST', '/notes//delete', login_required(delete_note_post), name='note_delete') VERIFIED, REAL RESULT ------------------------------ real row count before delete: 2 POST /notes/1/delete (authenticated) -> 302 Found / real row count after delete: 1 GET /notes/1 after delete -> 404 Not Found POST /notes/2/delete (unauthenticated) -> 302 Found /login real row count after unauthenticated attempt: 1 (unchanged) WHY THIS WORKS ------------------------------ The route reuses the exact same parameterized-DELETE pattern SqliteSessionStore's own load() method already uses for expired sessions in Chapter 6/7 — a `?` placeholder, never an f-string, even though request.params['id'] is already guaranteed to be a real int by the router's own converter and therefore "safe" by coincidence here. login_required wraps the handler exactly the same way it already wraps new_note_get/new_note_post — no new framework code, just the same existing wrapper applied to a third route. WHY THIS WORKS AS AN ANSWER ------------------------------ It verifies the delete by checking the real row count directly against the database, not just by trusting the 302 response — confirming the row genuinely disappeared, not just that the handler claimed to delete it. It also verifies the negative case (an unauthenticated attempt) using the identical row-count check, proving login_required blocks the delete before the DELETE statement is ever executed, not merely before the response is returned.