33 lines
1.6 KiB
Markdown
33 lines
1.6 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-22
|
|
located-in: [mesh-catalog modules/n8n, mesh-catalog modules/baserow]
|
|
fixed-by: 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](../080-a-cache-grant-lets-the-consumer-flush-the-server/00-report.md)),
|
|
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.
|