- Issue created by @texas-bronius
- Status changed to Postponed: needs info
about 1 month ago 3:44pm 17 December 2024
Status Dashboard Client site configuration form (Client Secret field, but that's the only field on the form) lacks cache context to automatically clear its config cache when the form is saved. As a result, a client secret can be updated in the client config form, but the client whole-site cache needs to be cleared and as a separate step before the updated client secret is offered for the access check of incoming Dashboard request.
With a known-working Status Dashboard + Status Dashboard Client site+secret pairing already set up:
* In Status Dashboard Client (client site) config, change client secret to an incorrect, non-matching value.
* In Status Dashboard (dashboard site), run cron to initiate another Client Status pull with the original, correct client secret.
Status Dashboard Client should fail to validate incoming Dashboard request and respond with 403.
Status Dashboard Client fails to deny the incoming Dashboard request with the old, matching secret and instead responds with 200 + status info.
Alternatively, this how-to-reproduce could easily be replicated the opposite way, correcting from non-matching to matching, but the initial test case feels more likely to be positively verifiable if you do it this weirdly reversed way :)
Did not look into it, but a simple cache context (cache keys or cache tags) can be added to the configuration form array `#cache` attribute referring to any of your configuration levels (in this case, it's just the one field, but it maybe ought to be a bit broader to the client module in case something new is added later: Then it can be narrowed if necessary).
Friendly note: What a super-simple module and setup! Thank you for building and sharing it!
Active
2.0
Code