Write the notes in an app, a school day at a time
The notes existed but there was nowhere to write them: a CLI command on a laptop, a tool call through Claude, or a file in a Docker volume. None of those is reachable from a phone in a lesson, which is where notes are actually taken. So: `/app`, served only when WEB_PASSWORD is set. A login, the day's notes, and a settings page for the Schulcloud token — the one surface here meant for a person rather than a program. The shape follows how the notes are written: one note per school day, one `##` heading per lesson, prose and lists and tables beneath. That turns out to be the design decision that matters, twice over. First, it is what lets WebUntis earn its keep. Opening a day with no note fills in that day's lessons — numbered, with times, teacher and room, cancellations dropped and substitutions marked. Retyping the timetable is exactly the work the second upstream exists to avoid, and "Stunden ergänzen" tops up a note started before the day ended without touching what is already written. Second, it changes how notes are indexed. A day note is indexed per lesson, not whole: search answers "my own note, Deutsch, 18.09.2026" rather than "my own note, Friday", and `list_notes subject=Deutsch` finds a day whose frontmatter names no subject at all. Indexed whole, every hit would read as a weekday and "what did we do in Deutsch" would match notes whose other five lessons were something else. `lessonHeading` and `subjectFromHeading` are a loop — the app writes the heading, the indexer reads the subject back out — and a test holds them to it. Notes taken in a lesson cannot be retaken, so the editor is built around not losing them: autosave, every keystroke mirrored to local storage, a save when the phone locks, and a fallback to the local copy when the request never arrives. A save that would overwrite a version the editor never saw is refused and the choice handed back — the notes folder is synced and open in more than one place, and a phone must not silently win over a laptop. `replaceNote` is separate from `writeNote` for that reason: never-overwrite is right for `add_note` and exactly wrong for an editor. WEB_PASSWORD is the first credential here a human types, so it is the first that can be guessed: scrypt at startup, never stored or compared in the clear, per-address rate limiting — which is not decoration, since the scrypt cost is itself a denial-of-service vector without it. The session is a signed HttpOnly SameSite=Strict cookie whose key is derived from the password, so changing it logs everyone out and there is no second secret to keep. It opens /api, because a session is the user, and never /mcp, because nothing in a browser speaks MCP. Also here, because the app made them matter: frontmatter now reads the indented `- item` list form editors write, so an Obsidian vault round-trips its tags; and a four-digit folder is a filing scheme, not a subject, so `2026/` does not file a school year under one. 357 tests; 106/107 smoke against the local instance, the one failure being the H5P service that instance does not run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
39
docs/AUTH.md
39
docs/AUTH.md
@@ -251,15 +251,50 @@ access log entry is written. Rotating it means a new value, a recreated
|
||||
container, and re-adding the connector. Prefer the connector token wherever a
|
||||
header can be sent: a URL is copied into more places than a header is.
|
||||
|
||||
### The app password, for a person
|
||||
|
||||
`WEB_PASSWORD` is unlike every other credential here: it is typed by a human, on
|
||||
a phone, in a lesson. That single fact drives its whole design.
|
||||
|
||||
- **It is a passphrase, not a token.** `config.ts` insists on 12 characters and
|
||||
nothing else; demanding punctuation would buy little next to length, and the
|
||||
failure mode of a fussy rule is a shorter password, not a better one.
|
||||
- **It is never stored in the clear.** scrypt (N=16384) at startup; a login
|
||||
hashes the attempt and compares in constant time. The error states the rule
|
||||
and never echoes the value.
|
||||
- **Logins are rate-limited per address**, eight failures in fifteen minutes.
|
||||
Not optional: a password is guessable in a way a 32-byte token is not, and the
|
||||
scrypt cost that makes guessing expensive is itself a denial-of-service vector
|
||||
without a limiter in front of it.
|
||||
- **The session is a signed cookie**, `HttpOnly` and `SameSite=Strict` — the
|
||||
latter standing in for CSRF tokens, since nothing links into the app from
|
||||
anywhere else. 30 days, because the alternative is a login screen at the start
|
||||
of a lesson.
|
||||
- **The signing key is derived from the password**, so changing it invalidates
|
||||
every session that exists. No second secret, nothing to store, and the
|
||||
behaviour anyone changing a password already expects.
|
||||
- **The cookie opens `/api` and not `/mcp`.** A session *is* the user, and the
|
||||
app is built on `/api` — but nothing in a browser speaks MCP, and a surface
|
||||
that is not needed is not offered.
|
||||
|
||||
Unset, the app is not served at all. A login screen that no password can open is
|
||||
worse than no page, because it looks like a way in.
|
||||
|
||||
## Blast radius
|
||||
|
||||
Every path in this server is a `GET`, including the `api_get` escape hatch,
|
||||
which rejects anything not starting with `/api/` and anything carrying a scheme
|
||||
or host. Someone who obtained both the endpoint URL and `MCP_AUTH_TOKEN` — or
|
||||
the connector token, or the secret MCP path — could read this account's
|
||||
Schulcloud data; they could not
|
||||
the connector token, the secret MCP path, or the app password — could read this
|
||||
account's Schulcloud data; they could not
|
||||
post, submit, delete, or otherwise act as the user. With `MCP_AUTH_TOKEN` they
|
||||
could also call `PUT /api/token`, but it accepts only a live token for the same
|
||||
account, so the most it can do is hand the server a session the owner already
|
||||
has. Keep it that way — adding a single write tool would change that property
|
||||
entirely.
|
||||
|
||||
The app password and `MCP_AUTH_TOKEN` additionally reach the notes: they can
|
||||
read, write and overwrite files under `NOTES_DIR`, and nothing outside it —
|
||||
`safeComponent` and `resolveWithin` are what make that a property rather than a
|
||||
hope. That is the only write anywhere in this server, and it touches the user's
|
||||
own files, never Schulcloud. `NOTES_READONLY=1` removes even that.
|
||||
|
||||
Reference in New Issue
Block a user