Phase 1: accounts and sessions

Implements PLAN.md Phase 1. A client can now register, log in, manage its
devices and set its profile; an operator can create accounts and flip the
runtime switches. There are still no rooms and no real /sync.

userapi: accounts, argon2id passwords in PHC format, devices, access and
refresh tokens stored as SHA-256 hashes, account data and the admin flag.
Its storage interface is storage.UserStore, implemented once in sqlstore
with `?` placeholders; the postgres driver supplies a rebind function and
unique-violation recognition rather than keeping a second copy of thirty
statements. Timestamps in these tables are int64 milliseconds, the unit the
Client-Server API uses on the wire.

Client-Server API: register (user-interactive auth with m.login.dummy and
optional registration tokens), register/available, token validity, login
with m.login.password, logout, logout/all, refresh, account/whoami,
capabilities, devices/* with password-gated deletion, profile/*, global and
per-room account data.

GET /sync is a deliberate placeholder: it answers a valid token with an
empty but well-formed response and refuses a revoked one. Phase 1 has no
rooms, so that is the whole truth, and it is what makes session revocation
observable. Phase 4 replaces it with the syncapi.

Auth middleware resolves a bearer token (header or the legacy query
parameter) to a device and user, answering an expired token with the soft
logout the spec asks for. Rate limiting is a token bucket per endpoint class
keyed on the client address, returning M_LIMIT_EXCEEDED with retry_after_ms.

adminapi v1 under /_warp/admin/v1: admin-only auth via a normal Matrix
token, GET/PUT /federation and /registration driving internal/settings and
reporting a config-pinned switch as a 409, GET/POST /users, GET /stats.

warp create-account [--admin] creates the first account straight in the
database, so a new install with registration off has a way in.

Complement is wired up for the federation=off profile: an image meeting its
contract, an entrypoint that configures Warp entirely from WARP_*
variables, and a runner that builds, clones and executes the target set
(TestRegistration, TestLogin, TestDeviceManagement). It has not been run
yet -- there is no container runtime on the development machine -- so the
three tests' assertions were read from the Complement sources and pinned as
httptest tests instead, and CI gained a job that runs the real thing.

Also fixes a .gitignore bug from Phase 0: the unanchored `warp` pattern,
meant for the built binary, also matched the directory server/cmd/warp and
silently excluded the entire command package from the repository. The
binary patterns are now anchored to the repository root, and cmd/warp is
committed for the first time.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

server/internal/clientapi/accountdata.go

@@ -0,0 +1,154 @@
+package clientapi
+
+import (
+	"encoding/json"
+	"errors"
+	"net/http"
+	"strings"
+
+	"github.com/dariuszjaniak/warp/server/internal/httputil"
+	"github.com/dariuszjaniak/warp/server/internal/userapi"
+)
+
+// MaxAccountDataSize caps one account data blob. The spec sets no limit, but
+// account data is sent down /sync in full on every initial sync, so an
+// unbounded blob is an unbounded sync.
+const MaxAccountDataSize = 64 * 1024
+
+// typeFullyRead is the account data type the spec reserves: it is set
+// through POST /rooms/{roomId}/read_markers, which keeps the read marker and
+// the receipt in step, so writing it directly is refused.
+const typeFullyRead = "m.fully_read"
+
+// handleGetAccountData implements
+// GET /_matrix/client/v3/user/{userId}/account_data/{type}.
+func (c *ClientAPI) handleGetAccountData(w http.ResponseWriter, r *http.Request, auth userapi.Authenticated) error {
+	return c.getAccountData(w, r, auth, "")
+}
+
+// handleGetRoomAccountData implements the per-room variant.
+func (c *ClientAPI) handleGetRoomAccountData(w http.ResponseWriter, r *http.Request, auth userapi.Authenticated) error {
+	roomID := r.PathValue("roomID")
+	if err := validateRoomID(roomID); err != nil {
+		return err
+	}
+	return c.getAccountData(w, r, auth, roomID)
+}
+
+func (c *ClientAPI) getAccountData(w http.ResponseWriter, r *http.Request, auth userapi.Authenticated, roomID string) error {
+	// Account data is private, so even a read is only ever of one's own —
+	// an admin reading it would be reading a user's client settings, which
+	// the admin API has no business doing either.
+	localpart, err := c.requireOwnAccountData(auth, r.PathValue("userID"))
+	if err != nil {
+		return err
+	}
+	dataType := r.PathValue("dataType")
+	if dataType == "" {
+		return httputil.MissingParam("An account data type is required")
+	}
+
+	content, err := c.users.AccountData(r.Context(), localpart, roomID, dataType)
+	switch {
+	case errors.Is(err, userapi.ErrNoSuchAccountData):
+		return httputil.NotFound("Account data not found")
+	case err != nil:
+		return err
+	}
+
+	// The stored bytes are the client's own JSON and go back out verbatim,
+	// so they are written directly rather than round-tripped through a map.
+	w.Header().Set("Content-Type", "application/json")
+	w.WriteHeader(http.StatusOK)
+	if _, err := w.Write(content); err != nil {
+		httputil.LoggerFrom(r.Context()).Debug("writing account data failed", "error", err)
+	}
+	return nil
+}
+
+// handlePutAccountData implements
+// PUT /_matrix/client/v3/user/{userId}/account_data/{type}.
+func (c *ClientAPI) handlePutAccountData(w http.ResponseWriter, r *http.Request, auth userapi.Authenticated) error {
+	return c.putAccountData(w, r, auth, "")
+}
+
+// handlePutRoomAccountData implements the per-room variant.
+func (c *ClientAPI) handlePutRoomAccountData(w http.ResponseWriter, r *http.Request, auth userapi.Authenticated) error {
+	roomID := r.PathValue("roomID")
+	if err := validateRoomID(roomID); err != nil {
+		return err
+	}
+	return c.putAccountData(w, r, auth, roomID)
+}
+
+func (c *ClientAPI) putAccountData(w http.ResponseWriter, r *http.Request, auth userapi.Authenticated, roomID string) error {
+	localpart, err := c.requireOwnAccountData(auth, r.PathValue("userID"))
+	if err != nil {
+		return err
+	}
+	dataType := r.PathValue("dataType")
+	if dataType == "" {
+		return httputil.MissingParam("An account data type is required")
+	}
+	if dataType == typeFullyRead {
+		return httputil.BadJSON("%s may only be set through /rooms/{roomId}/read_markers", typeFullyRead)
+	}
+
+	// The content is stored as the client sent it, so it is read as raw
+	// JSON and only checked for being a JSON object at all.
+	var content json.RawMessage
+	if err := httputil.DecodeJSON(w, r, &content); err != nil {
+		return err
+	}
+	if len(content) > MaxAccountDataSize {
+		return httputil.NewError(http.StatusBadRequest, httputil.ErrCodeTooLarge,
+			"Account data must be at most %d bytes", MaxAccountDataSize)
+	}
+	if !json.Valid(content) {
+		return httputil.NotJSON()
+	}
+	if trimmed := strings.TrimSpace(string(content)); !strings.HasPrefix(trimmed, "{") {
+		return httputil.BadJSON("Account data content must be a JSON object")
+	}
+
+	if err := c.users.SetAccountData(r.Context(), localpart, roomID, dataType, content); err != nil {
+		return err
+	}
+	httputil.WriteJSON(w, http.StatusOK, struct{}{})
+	return nil
+}
+
+// requireOwnAccountData resolves the path's user ID and insists it is the
+// caller's own. Unlike a profile, account data is not something an admin may
+// reach into: it is the user's client configuration.
+func (c *ClientAPI) requireOwnAccountData(auth userapi.Authenticated, pathUserID string) (string, error) {
+	localpart, err := c.users.ParseLocalUserID(pathUserID)
+	switch {
+	case errors.Is(err, userapi.ErrForeignServer):
+		return "", httputil.Forbidden("Cannot access the account data of another server")
+	case err != nil:
+		return "", httputil.InvalidParam("%s is not a valid user ID", pathUserID)
+	}
+	if localpart != auth.Localpart {
+		return "", httputil.Forbidden("Cannot access the account data of another user")
+	}
+	return localpart, nil
+}
+
+// validateRoomID checks the shape of a room ID in a path.
+//
+// Phase 1 has no rooms, so there is nothing to check it against: room
+// account data is simply a second key space, and a client may set it for a
+// room it has not joined. The full check — that the room exists and the user
+// is in it — belongs to the roomserver in Phase 3.
+func validateRoomID(roomID string) error {
+	switch {
+	case roomID == "":
+		return httputil.MissingParam("A room ID is required")
+	case !strings.HasPrefix(roomID, "!"):
+		return httputil.InvalidParam("%s is not a valid room ID", roomID)
+	case len(roomID) > 255:
+		return httputil.InvalidParam("Room IDs must be at most 255 bytes")
+	}
+	return nil
+}