1.6 KiB
status, opened, located-in, fixed-by
| status | opened | located-in | fixed-by | ||
|---|---|---|---|---|---|
| resolved | 2026-09-22 |
|
mesh-catalog multiple-fixes (neither module takes the shared cache — baserow runs its own, n8n in its shipped mode needs none); mesh-lab multiple-fixes (a check that every catalogue module taking the cache presents the login; the two-node bed asserts baserow's own cache answers) |
081 — A cache consumer does not use the login it was granted
Symptom
Two catalogue modules require the cache and are given a login and a password under a keyspace of their own (issue 080), and neither tells its software the login: each hands it the host, the port and the password only, so the software authenticates as the server's default user and writes wherever it likes — or is refused, if the default user is closed. The grant is honoured by the provider and ignored by the consumer.
Found on review of issue 080, by reading the two manifests. Not run: no bed installs either module against the catalogue's cache and reads what it wrote.
Why it matters beyond the instance
A grant is two ends agreeing. The provider's end is checked by the grant bed; the consumer's end, that the software actually presents what it was given, is checked by nothing but the module working — and a module that works as the default user works.
What would close it
Each module passes the login it was bound (${bound:redis-cache:as}) to its software's username
setting, and a bed installs one of them against the catalogue's cache and reads back that its keys
sit under its login.