Use one name for each thing the UI shows (closes #399)
check / check (push) Successful in 3m21s
check / check (push) Successful in 3m21s
The UI gave one thing several names. The `database` type is now Archive in the type list, on its badge and on the edit page, and its settings read "Archive expiry" and "Archive rotation" everywhere. The retry field is "Delivery attempts", with help text, errors and the target list saying it counts every attempt; a stored 0 shows as one attempt. The target list uses one capitalisation. The navbar says "Sign out", the sign-in page "Sign in", and the resubmit notice "webhook" instead of "source". The README follows. Stored values, their meaning, routes and form field names are unchanged. Model: opus-5-5
This commit was merged in pull request #491.
This commit is contained in:
@@ -313,7 +313,7 @@ itself; a production deployment puts a reverse proxy in front of it
|
||||
[Deployment behind a reverse proxy](#deployment-behind-a-reverse-proxy)),
|
||||
and the proxy reaches it over loopback. A default that bound every
|
||||
interface would leave that cleartext port answering the internet
|
||||
alongside the proxy — the admin login form and the receiver, in the
|
||||
alongside the proxy — the admin sign-in form and the receiver, in the
|
||||
clear, on a port nobody chose to publish. Reaching webhooker from
|
||||
another host is therefore something you configure, not something you
|
||||
get by default.
|
||||
@@ -835,7 +835,7 @@ reports.
|
||||
`-p 127.0.0.1:8080:8080`. Either way the port must reach the proxy
|
||||
and nothing else; widen it only with a firewall or a publish
|
||||
address in front of it. A cleartext port answering the internet
|
||||
serves the admin login form and the unauthenticated receiver with
|
||||
serves the admin sign-in form and the unauthenticated receiver with
|
||||
no TLS at all, and the proxy in front of it changes nothing about
|
||||
that.
|
||||
2. **Make sure the environment is not `dev` (leave
|
||||
@@ -1617,10 +1617,11 @@ event routing.
|
||||
The new webhook form can also give the webhook its first targets: an
|
||||
optional HTTP target URL creates an `http` target named `HTTP`, and the
|
||||
archive checkbox creates a `database` target named `Archive` whose
|
||||
`expiry` is the pruning chosen beside it (never, 1h, 12h, 24h, 30d, 90d
|
||||
or 365d) and whose `rotation` is the rotation chosen below that (none,
|
||||
monthly, daily or hourly). Both are validated as on the add target form,
|
||||
and the webhook and its targets are created together or not at all.
|
||||
`expiry` is the archive expiry chosen beside it (never, 1h, 12h, 24h,
|
||||
30d, 90d or 365d) and whose `rotation` is the rotation chosen below that
|
||||
(none, monthly, daily or hourly). Both are validated as on the add
|
||||
target form, and the webhook and its targets are created together or
|
||||
not at all.
|
||||
|
||||
| Field | Type | Description |
|
||||
| ---------------- | ------- | ----------- |
|
||||
@@ -1707,7 +1708,7 @@ events should be forwarded.
|
||||
| `type` | TargetType | One of: `http`, `slack`, `database`, `log` |
|
||||
| `active` | boolean | Whether deliveries are enabled (default: true) |
|
||||
| `config` | JSON text | Type-specific configuration |
|
||||
| `max_retries` | integer | Total delivery attempts for `http` and `slack` targets, not retries on top of the first: 0 is a single fire-and-forget attempt with no retries and no circuit breaker, and a value of N makes N attempts in all, with exponential backoff and a per-target circuit breaker. Ignored by `database` and `log` targets |
|
||||
| `max_retries` | integer | Total delivery attempts for `http` and `slack` targets, not retries on top of the first: 0 is a single fire-and-forget attempt with no retries and no circuit breaker, and a value of N makes N attempts in all, with exponential backoff and a per-target circuit breaker. Ignored by `database` and `log` targets. The web UI labels it Delivery attempts |
|
||||
|
||||
**Relations:** Belongs to Webhook. Has many Deliveries.
|
||||
|
||||
@@ -1736,7 +1737,9 @@ events should be forwarded.
|
||||
expiry in plain units, such as "30 days", and the rotation. No external
|
||||
delivery and no retries; an archive write failure fails the delivery.
|
||||
See the database target section under "Per-Webhook Event Databases"
|
||||
for the full semantics.
|
||||
for the full semantics. The web UI calls this type an archive: its
|
||||
badge, the add target form's type list and the target edit page say
|
||||
so, and its settings are labelled Archive expiry and Archive rotation.
|
||||
- **`log`** — Write the event to the application log (stdout). Useful
|
||||
for debugging.
|
||||
|
||||
@@ -2588,7 +2591,7 @@ The query string is never logged; it is replaced by the fixed marker
|
||||
`/.well-known/healthcheck` and `/s/*` answer 200 to anyone with no rate
|
||||
limiter in front of them, so a query on a fixed 200 URL would otherwise
|
||||
buy the same amplification as an invented path. Nothing debuggable is
|
||||
lost: the only query parameters this service reads are the login page's
|
||||
lost: the only query parameters this service reads are the sign-in page's
|
||||
`next`, the page to return to, and `notice`, which names the line a page
|
||||
shows after an action.
|
||||
|
||||
@@ -2743,9 +2746,9 @@ wider than it:
|
||||
| `... rate limit exceeded` (429) | `WARN` | path | yes, on the receiver |
|
||||
| `auth middleware: unauthenticated request` | `DEBUG` | path, method | yes, by definition |
|
||||
| `entrypoint not found` | `DEBUG` | entrypoint UUID | yes, on the receiver |
|
||||
| `user not found` / `invalid password` | `DEBUG` | username | yes, on the login form |
|
||||
| `login failure limit exceeded` (429) | `WARN` | path | yes, on the login form |
|
||||
| `password verification capacity exhausted` | `WARN` | path | yes, on the login form |
|
||||
| `user not found` / `invalid password` | `DEBUG` | username | yes, on the sign-in form |
|
||||
| `login failure limit exceeded` (429) | `WARN` | path | yes, on the sign-in form |
|
||||
| `password verification capacity exhausted` | `WARN` | path | yes, on the sign-in form |
|
||||
|
||||
`DEBUG` being off by default is not a bound. An operator turning it on
|
||||
to diagnose a flood must not thereby hand the flood an unbounded write,
|
||||
@@ -2793,7 +2796,7 @@ standard output on every statement that returned an error, including a
|
||||
plain record-not-found, at a level no operator setting reached. Two of
|
||||
this service's lookups miss by design on unauthenticated routes: the
|
||||
entrypoint lookup behind `/h/{uuid}` and the user lookup behind
|
||||
the login form, whose path segment and submitted username the client
|
||||
the sign-in form, whose path segment and submitted username the client
|
||||
picks outright. Every
|
||||
`gorm.Open` in the service now installs the adapter in
|
||||
`internal/gormlog` instead. It writes through the same `slog` logger as
|
||||
@@ -3081,14 +3084,14 @@ abuse limit later; they are tracked as future work.
|
||||
|
||||
| Method | Path | Description |
|
||||
| ------ | --------------- | ----------- |
|
||||
| `GET` | `/pages/login` | Login page (not rate limited). Its `next` parameter names the page to return to after login; anything but a path on this site is replaced with `/` |
|
||||
| `POST` | `/pages/login` | Login form submission. On success, redirects to the form's `next` when it is a path on this site, otherwise to `/`. Credentials are verified before any limit is consulted, so a correct password is never throttled; 5 FAILED attempts per minute per bucket per submitted username, then `429`. `503` if no verification slot frees up within 5s, or immediately if 16 requests are already queued for one (see [Rate Limiting](#rate-limiting)) |
|
||||
| `POST` | `/pages/logout` | Logout (destroys session) |
|
||||
| `GET` | `/pages/login` | Sign-in page (not rate limited). Its `next` parameter names the page to return to after signing in; anything but a path on this site is replaced with `/` |
|
||||
| `POST` | `/pages/login` | Sign-in form submission. On success, redirects to the form's `next` when it is a path on this site, otherwise to `/`. Credentials are verified before any limit is consulted, so a correct password is never throttled; 5 FAILED attempts per minute per bucket per submitted username, then `429`. `503` if no verification slot frees up within 5s, or immediately if 16 requests are already queued for one (see [Rate Limiting](#rate-limiting)) |
|
||||
| `POST` | `/pages/logout` | Sign out (destroys session) |
|
||||
|
||||
#### Authenticated Endpoints
|
||||
|
||||
A logged-out `GET` of any of these is redirected to `/pages/login` with
|
||||
its path and query as `next` when they fit in 2048 bytes, so logging in
|
||||
A signed-out `GET` of any of these is redirected to `/pages/login` with
|
||||
its path and query as `next` when they fit in 2048 bytes, so signing in
|
||||
returns to the page that was asked for.
|
||||
|
||||
| Method | Path | Description |
|
||||
@@ -3437,7 +3440,7 @@ check, see [The login endpoint](#the-login-endpoint).
|
||||
still evaluated, so roughly 27 guesses a second get through and the
|
||||
admin password has to carry that load (see
|
||||
[The login endpoint](#the-login-endpoint)). `GET` requests to the
|
||||
login page are not limited
|
||||
sign-in page are not limited
|
||||
- **Password-change rate limiting** via [go-chi/httprate](https://github.com/go-chi/httprate):
|
||||
sliding-window rate limiter, 5 POST attempts per minute per bucket.
|
||||
It runs behind session auth, so only a client already holding a
|
||||
|
||||
Reference in New Issue
Block a user