~bigbes/sr-ht-dolt

ref: b525a62b754afa38cc1aee0995eddae5f8a37214 sr-ht-dolt/cmd/doltsrht/main_test.go -rw-r--r-- 18.8 KiB
b525a62b — Eugene Blikh a day ago
authn: name the grant scope dolt.sr.ht/DATABASES

api-meta.json published the scope as lowercase "repos" while every other
service on the instance publishes it upper case — git.sr.ht/REPOSITORIES,
todo.sr.ht/TRACKERS, paste.sr.ht/PASTES, builds.sr.ht/JOBS. Upstream derives
those from a GraphQL enum; this service has no @access directive to derive
from, so the spelling was free and drifted.

It matters because meta.sr.ht compares the string verbatim. Its oauth2
blueprint fetches every service's api-meta.json once at import time and
validates a requested grant with `scope in service_scopes[svc]` — no case
folding, no aliasing. So a grant typed by hand as dolt.sr.ht/REPOS:RO was
refused, by analogy with every neighbouring service.

DATABASES rather than REPOS: that is what the surface calls the object
everywhere a user meets it — the GraphQL databases connection, the web pages,
the docs. The storage layer underneath still says "repo"; renaming that is a
deeper change and is not what a token grant names.

No backward compatibility. auth.Grants.Has is a map lookup, so a PAT minted
against the old spelling is refused rather than quietly honoured, and two table
cases assert that instead of leaving it implied. Deploying this is two-sided:
meta.sr.ht has to be restarted before anyone can mint a token carrying the new
name.

The federation gateway is unaffected — it forwards the client's Authorization
header to each service and never reads api-meta.json.

sr-ht-dolt-xic
bd2d8a36 — Eugene Blikh 4 days ago
doltsrht: serve /query and the api-meta.json beside it

The schema is mounted where /mcp is and for the same three reasons — before
web's same-origin group, before the cookie middleware, in a group of its own
— plus one of its own: it answers anonymous callers, so it cannot ride
core-go's WithSchema, whose router 401s an un-cookied request. It does need
the config and database middleware, which is why the group sits below them.

The file beside it is not optional. meta.sr.ht fetches api-meta.json from
every service it discovers and iterates each one's scopes to build the
personal-token page, so a service that mounts its own /query owes the
instance this too — and the scope list is what makes "dolt.sr.ht/repos:RO"
offerable there at all. The never-null rule that makes a mistake here a 500
for the WHOLE instance lives in ecore's apimeta; a test asserts the name this
service advertises is the one authn.RepoScope enforces.

README says what the surface serves and what it deliberately does not, and
that `hut graphql dolt` needs the patched hut — upstream segfaults on any
service outside its hard-coded list.
cd0b0c0f — Eugene Blikh 4 days ago
web: rename a database from its settings page

A database's name lives in two places — the metadata row and the on-disk
store directory its path names — so a rename has to move both. The order
is creation's: the row first, where a name already taken is refused by the
unique index before anything on disk changes, then the store, then the
handle the remotesapi memoized under the old path. A store that will not
move rolls the row back, so the two halves never disagree about where a
database lives; only a failed rollback is escalated to a human, because
it is the one outcome no later request can repair.

storage.MoveStore is one os.Rename behind the containment guard DeleteStore
already used, extracted here as containedPath. It refuses an occupied
destination outright: os.Rename over an empty directory would succeed and
swallow it.

No redirect is left behind — the old address simply stops resolving, as on
git.sr.ht — so an existing clone needs its remote replaced, and a companion
of a git repository is re-provisioned under its old name by the next push
to that repository. The README's quickstart now says both.
93e69910 — Eugene Blikh 4 days ago
storage: create databases empty so the first push needs no --force

Every automatic creation path wrote an "Initialize data repository"
commit through WriteEmptyRepo, and that commit is history. dolt decides
fast-forward on the client (actions.CanFastForward over the remotesapi),
so the server cannot forgive the collision: pushing a database that has a
root commit of its own — a beads tracker, anything grown locally — was
rejected as a non-fast-forward and could only land with --force. That is
the whole reason the companion-database recipe starts with a forced push.

push-to-create already provisioned an empty store for this exact reason.
Give the other two paths the same default: /internal/repos, whose caller
is git.sr.ht's post-update hook and therefore fires before its user has
ever pushed, now always provisions empty, and the web form does unless
its new "initialize with an empty commit" checkbox is ticked. The
checkbox buys what an empty store cannot offer — a database that can be
cloned before anything is pushed to it, since dolt refuses a store with
no commits as "contains no Dolt data".

Which is also why the overview of a database with no branches now teaches
push rather than clone: the clone box there quoted a command that could
not work. A store that fails to open is deliberately not treated as
empty — an unreadable database must not be advertised as a fresh one.
57adcc0a — Eugene Blikh 6 days ago
doltsrht: serve /mcp on the web listener
8ba716c3 — Eugene Blikh 11 days ago
instconf: take the origin and required-key helpers from ecore

Two copies of one function disagreed in this repo: hostFromOrigin returned an
error for a malformed origin and web's hostOf answered "localhost", which is a
guess that looks like an answer. Both are gone; the caller now names which half
it means, and both wanted OriginAuthority — a port is part of a sealed-URL host,
a JWT audience and the synthesized commit-author domain alike.

The startup checks become one Require, so an operator filling in a fresh
config.ini reads every missing key off one boot instead of one per restart. The
hook's internal-origin read becomes InternalOrigin, which falls back to the
external origin: an instance with only a public address is not misconfigured and
used to be refused. And the git-description mirror is wired only when git.sr.ht
has an API origin — web.Config already documented a nil Git as no mirroring, but
nothing produced one, so an instance without git.sr.ht met config.GetAPI's panic
on the first push.
e518fcb9 — Eugene Blikh a month ago
cmd: doltsrht and doltsrht-migrate binaries, module tidy