~bigbes/sr-ht-dolt

ref: cdb9195f8ddc7ec1026122d43ba5a318445af7ea sr-ht-dolt/web/handlers_internal.go -rw-r--r-- 6.8 KiB
d84a877c — Eugene Blikh 9 days ago
internalauth: take both ends of the internal protocol from ecore

The guard on /internal/repos and the header cmd/dolt-git-hook minted for it
were two hand-written halves of one protocol in two packages that shared no
type, no constant and no test. Both are now sr-ht-ecore/internalauth: Guard on
the receiving end, AuthorizationAs on the calling one, over one Auth struct.

The guard also pins the caller, which the old copy did not: core-go only asks
that a token name some client and node, and on an endpoint that provisions a
database for an arbitrary user that means any holder of the network key will
do. The pinned pair lives in core so the mint and the pin cannot drift apart.

The hook test now runs internalauth.Identify — the real receiving end — over
the header the hook produced, so the two ends are checked against each other
rather than against a third copy of the decode.
bf7897cd — Eugene Blikh 10 days ago
web: draw the chrome from sr-ht-ecore

The brand, the service switcher, the login block, the environment banner
and the database listing were a local port of core.sr.ht's nav — one of
five such ports on this instance, and they had already drifted. They are
now sourcecraft.dev/bigbes/sr-ht-ecore/chrome, the one copy every custom
service draws from.

Deleted: web/chrome.go entire (navEntry, networkOrder, networkExcluded,
buildNetwork, basePage, loginURL, logoutURL), templates/nav.html,
templates/icons/circle.svg (ecore inlines the identical SVG), the
repoList partial, and the local dict/shortHash duplicates.

Added: one chrome.Service built in newApp from our config section with
the hashed stylesheet href set on it, a chrome.Page per request through
app.page, chrome.Attach on every template set, and chrome.Funcs as the
base of the funcmap. Handlers embed chrome.Page in their view structs
instead of copying its fields; the row browser sets ContainerClass to
container-fluid, since its column count is the table's and not ours.

Three behaviour changes come with ecore's policy, all deliberate: the
profile link now prefers hub's ~username page when hub.sr.ht is
configured (it was always meta's /profile), the brand carries a fixed
15rem min-width so the switcher starts at the same x on every service,
and a binary built without a stylesheet renders bare rather than linking
an empty href. The nav test went with the code it tested — ordering,
exclusions and login URLs are ecore's to cover — and what replaced it
asserts only what is ours: that pages are drawn through the chrome at
all, and that the row browser is full-bleed.

The auth path is untouched: a foreign bearer token is still accepted as
a meta.sr.ht PAT.
e8a202e5 — Eugene Blikh 12 days ago
web: mirror the git twin's description onto companion databases

The internal create endpoint accepts a description, but its only caller
— dolt-git-hook — never sends one: git.sr.ht's push context does not
carry it. Companion databases therefore all sat descriptionless on the
dashboard while their git twins had perfectly good descriptions.

Resolve the description server-side instead: a GitDescriber dependency
(internal GraphQL query to git.sr.ht in the owner's name, the same
network-key trust the hook uses to reach us, pointed the other way) is
consulted on every /internal/repos call. A fresh companion is created
with the twin's description; for an existing one the push doubles as the
sync point — a changed, non-empty git description overwrites the stored
one. An empty git description never clobbers one set in dolt's own
settings, and every failure mode (no twin, git.sr.ht down, no resolver
wired) degrades to no mirroring. The lookup is capped at 3s so the
hook's own 5s POST timeout is never exceeded.

Adds testify as a direct dependency for the new tests.
ce06498a — Eugene Blikh 30 days ago
feat: auto-provision companion Dolt DBs from git.sr.ht pushes

Add a service-to-service path so pushing a git.sr.ht repo creates a matching
Dolt database at ~owner/name, ready before the user's first `dolt push`.

- web: POST /internal/repos, guarded by internal-IP + network-key `Internal`
  auth (not the browser cookie/CSRF). Resolves/mirrors the owner via
  auth.LookupUser, then CreateRepo + InitStore, rolling back the row if the
  store init fails. Idempotent: an existing companion returns 200, a fresh one
  201 — safe to call on every push.
- cmd/dolt-git-hook: the git.sr.ht post-update-script. Delegates every hook
  stage to the stock /usr/bin/git.sr.ht-update-hook unchanged (argv[0], stdin,
  env, exit code preserved; fail-closed if the delegate is missing), then on
  post-update POSTs the companion create and prints a one-time clone notice.
  Best-effort: never fails a push, degrades to a warning on any misconfig.

Tests cover the endpoint (provision/idempotent/rollback/bad-input) and the hook
(signed request round-trips through the guard's decryption, notice only on 201).