3.8 KiB
Requirements Clarification Questions — Master CMS Module (Round 2)
Your answers were very clear on the overall model. A few follow-up questions to resolve remaining ambiguities before generating the requirements document.
Clarification 1 — How does the slave CMS know the Master's URL?
Your Q4 answer says the client cannot configure this. But the slave still needs to know where to pull availability status from.
How is the Master URL configured on the slave CMS?
A) Developer sets it in the slave's appsettings.json at deployment time (e.g., MasterModule:MasterUrl) — clients see the config file but cannot change it via the UI
B) Environment variable only — completely invisible to the client in normal deployments
C) The Master registers itself with the slave at first connection — no manual config needed on slave side
D) Other (please describe after Answer: tag below)
Answer: C, but I want something to prevent the client from changing the url and this the slave being unable to contact the master. So the master should be able to check whether everything is still stored correctly. We might need an extra service that runs as a cronjob or something similar.
Clarification 2 — Authentication between Master and Slave
When the Master calls the slave's PUT /api/availability/status to set its availability, how does it authenticate?
A) The API key stored in the Master's CmsInstance record is sent as a header — the slave validates it as a special "master key"
B) The Master uses a JWT token from the slave (Owner account credentials stored in the Master's DB)
C) The slave exposes a separate unauthenticated (but secret-URL-protected) internal endpoint for this
D) A shared API key configured in both Master and slave appsettings.json
E) Other (please describe after Answer: tag below)
Clarification 3 — Slave Availability Cache Duration
Your Q3 answer mentions the slave caches the Master's availability status to reduce traffic. How long should this cache be valid?
A) Configurable — set in the slave's appsettings.json (e.g., MasterModule:CacheMinutes: 60)
B) Fixed at a reasonable default (e.g., 60 minutes) — no configuration needed
C) Session-based — re-check when the application restarts or a specific event occurs
D) Other (please describe after Answer: tag below)
Answer: A, but B as a fallback.
Clarification 4 — Slave's Fallback Behavior When Master is Unreachable
Your Q3 answer says: if the Master is unavailable, the slave falls back to its own DB value. What should the default value in the slave DB be before the Master has ever contacted the slave?
A) Available — default to open; the Master will disable it if needed
B) NotAvailable — default to closed; the Master must explicitly enable it after registration
C) Configurable per slave registration in the Master's CmsInstance record
D) Other (please describe after Answer: tag below)
Answer: A, this whole feature is a safety measure, but it should not block the client from doing anything when something doesn't work correctly.
Clarification 5 — Master UI: Adding / Removing Slave CMSes
On the /cms page the Owner manages slave CMS registrations. What actions should be available?
A) Add (name + URL + API key), view list with current status, toggle Available/NotAvailable, remove B) Add (name + URL + API key), view list with status — no remove (registrations are permanent) C) Full CRUD: add, edit (name/URL/key), view list with status, toggle, remove D) Other (please describe after Answer: tag below)
Answer: B, but also option to set status Available/NotAvailable/Inactive where Inactive makes it greyed out meaning the CMS is no longer used. Also the option to set a message when the master disables a slave. That should be mandatory.