🏆Capstone project: Project: Your List and Nobody Else's

Ownership, a login limit, and a log each work, and each has a test. This project states them as one policy, and closes the last gap in it: what happens when your own code fails.

The policy

Every request that reaches handle() is written down once, in five fields and without a credential. The book reads answer private, no-cache, and the five session routes answer no-store.

When your own code fails

The table says what the server does with requests it understands. One case is missing: a mistake in the server itself. Today an error inside route() escapes handle(). The client gets no answer from your code, and the log gets no line.

handle() is the one place every response your routes build passes through, so the guard goes there. (The 411, 413, and 400 that read_body answers before a route runs do not pass through it, and are not logged.) Wrap the call to route in try. In except Exception:, build the answer:

• traceback.print_exc() prints the traceback to standard error, where the operator reads. The traceback module is new, the project already imports it, and this one call is all you need from it.

• json_error(500, ...) with a fixed message of your choice.

• cache-control set to no-store.

• An empty body when the method is HEAD. That is the rule from HTTP with Python, which route did not get to apply this time.

Keep the log line after the try, so that the failed request is logged too, as a 500. Lesson 5 wrote log_line so that it cannot fail, so nothing after the try can raise.

Why Exception, and not a bare except? Pressing Ctrl+C raises KeyboardInterrupt, which is how you stop a server from the keyboard. KeyboardInterrupt is not an Exception, so this guard lets it through, and the server still stops.

Python in Practice taught you to catch narrowly, and that still holds everywhere else. This is the one place where a wide catch is the right boundary, and it is the outermost one: whatever went wrong inside route(), the client gets an answer and the operator gets the detail.

The operator’s stream is the right place for a traceback. It is not a safe place. A traceback can hold a value from a request, so the people who may read standard error should be few.

Milestones

1. The attack test. A client can already make your server raise. Send GET /books/ followed by 5,000 digits: int() refuses a number that long with a ValueError, the error escapes handle(), and the client gets no answer at all. A guard is for that mistake and for the ones nobody has found yet. The test uses a failure that is quicker to write down: it breaks the state by hand. With steps.keyed_state() and a token for ana, it removes the books with state.pop("books") and sends GET /books. It asserts status 500, and that neither b"Traceback" nor b"KeyError" is in the body. Run python -m pytest -q: 1 failed, 20 passed. The KeyError escapes handle() and fails the test.

2. The guard. Write it in handle, as described above.

3. Everything together. python -m pytest -q ends with 21 passed. Then run both scenarios:

python pl_sec.py other-reader
python pl_sec.py guessing

Each ends with your server’s log. In the first you can read ben’s attempt:

1000000 DELETE /books/1 404 ben

4. The findings. In SECURITY.md, rows F8 and F9 each name their test and say closed.

What is still open

F14 from Chapter 5 is still open: a token that leaks works until it expires.

And look at the books once more. A title may be any text a client sends, up to the body limit. Your server stores it and hands it back without a second look. The next chapter gives a book three more fields, and asks what happens when text from a request is read as something more than text.