lower quota severity and obscure private repos #43

2026-09-09T17:09:55+02:00

mi commented

2026-09-09 17:09:55 +02:00

No description provided.

mi added 2 commits 2026-09-09 17:09:55 +02:00

system: a quota to raise is yellow, a filling volume is red 4c5b1124a8

A group quota at 92 % was shown in the same red as a disk about to stop the
machine, and made the verdict read 'overloaded'. The two are not the same
thing: a quota is raised by asking, and nothing stops while it is being asked
for, so it is a warning. Red is kept for what cannot be asked for — a volume
that is the budget, or one running out behind a quota, where raising the quota
would buy nothing.

The chips take their colour from the page's own ok/watch/critical vocabulary
now rather than from the verdict, so the verdict keeps saying 'upgrade' while
the colour says how loudly. The machine verdict follows the same rule.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

server: hide private repositories from visitors without the control token f6ccd2875a

The build pages are readable by anyone, and they name every branch, every
commit and every artifact of every served repository. For a private repository
that is more than a passer-by should see.

A repository's visibility is not configured: the forge already knows it, and
asking it is the one answer that cannot drift. The Gitea API is asked once per
repository and the answer cached; where no forge is configured the repository
is public exactly as before, and where a forge is configured but silent the
repository counts as private until it answers — a page on the internet must not
reveal a repository because a network call failed.

The redaction happens on the server, before anything leaves it: the name becomes
'hidden private repo', branch, build name and commit become 'n/a', the artifact
key goes and with it the artifact links, the log and the permanent branch url,
and the links into the forge disappear with the repository's identity. The
shapes are untouched, so the page renders a hidden repository like any other and
nothing in the frontend has to know. Artifacts, logs and the artifact page
answer the same 404 an unknown key gets.

For that the server has to know what the browser holds before any script runs,
so the token is mirrored into a cookie. The cookie grants visibility only:
restarting or deleting still requires the header, which a foreign page cannot
set. The order button follows the same rule — GET /api/system reports no hosting
without the token, so neither the button nor the webspace name reaches a visitor.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mi added 1 commit 2026-09-09 17:26:18 +02:00

ui: grey out the actions without a valid control token 149ef015bf

Restart, delete and cancel used to ask for the token on the first click and
fail if it was wrong. Now the server, which is the only party that can tell a
valid token from a stale one, puts its verdict on the page and the buttons are
rendered disabled: the row still says what exists, it is just not yours.

With every action disabled there would be nothing left to click that asks for
the token, so the header carries a key button that takes it and gives it back.
It reloads afterwards, because what may be shown and done is decided from the
cookie when the page is fetched.

Also: version 1.5.0, its release notes, and the PR-doc for PR#43.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mi merged commit 80ba258211 into main

2026-09-09 18:49:25 +02:00

mi deleted branch quota-severity

2026-09-09 18:49:25 +02:00

mi referenced this pull request

2026-10-05 18:46:31 +02:00

RAM and disk sizing advice split into their steps, every advice chip tested (v1.37.4) #123

mi referenced this issue from a commit

2026-10-05 18:58:31 +02:00

RAM and disk sizing advice split into their steps, every advice chip tested (v1.37.4) (#123)

Sign in to join this conversation.