(skywalking-horizon-ui) 11/11: docs(changelog): one entry per setting, not one per revision

[wu...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

wu-sheng pushed a commit to branch refactor/audit-drop-token-use
in repository https://gitbox.apache.org/repos/asf/skywalking-horizon-ui.git

commit 92588a2445acc5f91a30f838d604d2b9eb0ed746
Author: Wu Sheng <wu...@foxmail.com>
AuthorDate: Sun Aug 23 22:53:56 2026 +0800

    docs(changelog): one entry per setting, not one per revision
    
    The two `server.trustProxy` bullets described the same setting from two
    rounds of work. A release file is read once, top to bottom, so the /0 refusal
    belongs in the sentence that already explains why `true` is refused.
---
 docs/changelog/1.0.0.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/docs/changelog/1.0.0.md b/docs/changelog/1.0.0.md
index 858ba62d..7fcf7c33 100644
--- a/docs/changelog/1.0.0.md
+++ b/docs/changelog/1.0.0.md
@@ -6,9 +6,8 @@
 - **It records only what a valid credential produced, and that is a security property rather than a scoping decision.** Successful sign-ins (password, LDAP, break-glass, single sign-on) and exactly two refusals — both of which happen *after* authentication already succeeded: an account with no roles, and an LDAP account matching no group mapping. A wrong password, an unknown user, an expired token, a mangled SSO callback: those stay in the application log, because they are the ones an an [...]
 - **A database can never delay a sign-in, and cannot stop one.** Sign-ins are buffered in memory and written in the background in batches, so the login path performs no database work at all — an unreachable Postgres is invisible to the person signing in. When it does go down you get one `error` line naming a sanitised cause and one `info` line when it returns saying how long it was out and how much was lost, rather than one line per sign-in; the page shows an explicit "cannot be reached" [...]
 - **`audit:read` is not granted by a wildcard.** A role holding `"*:read"` gets every other read in Horizon and not this one, and neither does the read-only scope an MCP client is granted by default — because the log holds verified email addresses and client addresses, and a read-only integration should not acquire them as a side effect. Grant it by name, or use the administrator role. There is no write permission and no delete: the log is append and query.
-- **`server.trustProxy` is new, and `true` is refused.** Without it Horizon records the address it is talking to, which behind an ingress is the ingress — every row naming the same host. Set a hop count (`1` for a single proxy) or your ingress address/CIDR. `true` is rejected at startup rather than accepted: it trusts the whole `X-Forwarded-For` header, so any caller could choose the address Horizon writes down, and an address column that looks authoritative while being attacker-chosen i [...]
+- **`server.trustProxy` is new, and `true` is refused.** Without it Horizon records the address it is talking to, which behind an ingress is the ingress — every row naming the same host. Set a hop count (`1` for a single proxy) or your ingress address/CIDR. `true` is rejected at startup rather than accepted: it trusts the whole `X-Forwarded-For` header, so any caller could choose the address Horizon writes down, and an address column that looks authoritative while being attacker-chosen i [...]
 - **Token usage is counted on its own tab, at its own grain.** A sign-in is a person arriving; token traffic is a machine at work, and stacking the two in one list let a busy script outweigh every human sign-in beside it. The **Token usage** tab keeps **one row per credential per hour** — never one per request — grouped by hour, newest first, over the last 2, 6 or 12 hours or a **Custom…** range you pick (twelve hours is the widest it will read: the picker refuses a longer custom range r [...]
-- **`server.trustProxy` refuses a /0 block as well as `true`.** `0.0.0.0/0` and `::/0` match every address there is, so they are `true` written as a CIDR — the same attacker-chosen client address arriving past the check that refuses `true` by name. Name the ingress address or its real prefix instead.
 - **The hourly write budget is a safety valve, not a throttle.** `maxRowsPerHour` (1000 per Horizon process) bounds what one node can add to the table in an hour. A fifty-person team produces on the order of a hundred rows a *day*, so reaching it means something is wrong — and the page shows the count that was refused rather than silently discarding it. The summary block is honest about being estimated and per node; the list beside it is the exact record.
 
 ### AI assistant (new)