DongHyeonkaandClaude Opus 5
5f10b791d3
Snapshot of the in-flight state that already existed, identically, in both this worktree and the main checkout before this session began: the initial HTTP Client platform implementation (previously untracked), the redis-lab removal, and the JPA / object-storage / notification integration work. Kept separate from this session's HTTP Client review response, which lands in the following commit, so the two bodies of work stay reviewable apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ACL accounts
One file per CommandAccess level. Each account is deliberately narrower than the SDK's own rules:
the account is the last enforcement boundary and a permit issued inside the process never widens it,
so a mistake in the SDK is still refused by the server.
A Redis ACL file accepts nothing but complete user lines — no comments and no line continuations —
which is why the rationale lives here instead of inline. Password material is supplied at deploy
time; none of these files carries one.
| File | Account | Grants |
|---|---|---|
application.acl |
CommandAccess.APPLICATION |
the typed data-structure commands over prod:*, with the dangerous and deprecated names denied |
application-advanced.acl |
APPLICATION_ADVANCED |
the above plus pub/sub, transactions, and the registered-script path. EVAL is absent: only EVALSHA of an already loaded digest is reachable |
raw-gateway.acl |
RAW_GATEWAY |
exactly the commands the catalog classifies RAW_ONLY, and nothing else |
all-accounts.acl |
– | the four accounts concatenated; Redis takes one aclfile, so this is what a deployment loads |
admin-readonly.acl |
ADMIN_READONLY |
read-only diagnostics. Every destructive counterpart is denied here and blocked in the command policy catalog — two independent controls for the same rule |