docs(access-control): say an access rule pattern must match the whole value - #7019
Conversation
The OpenAPI descriptions and the console's drawer copy called these fields "regexps" and stopped there, which is what leads an operator to write "staging" and expect the staging host. Anchoring is the part they have to know, so state it where the field is described rather than leaving it to the reader to discover from behaviour. The examples name the failure the wording is there to prevent: "root" authorizes the login root and not notroot; "staging" selects the device named staging and not staging-db.
FirewallFilter, FirewallRuleFields, FirewallRule and FirewallRuleUpdate had no caller in either repo. Firewall rules are an enterprise feature, so the live types are cloud's own FirewallRule and FirewallRuleFilter in cloud/pkg/models; from shellhub cloud takes only Taggable, Tag, Device and FirewallConnection. The copy here was a second definition of the same concept that no code could disagree with, because no code read it. Every module still builds without it, which is the evidence it was dead.
The access policy device filter was the surface the earlier pass missed. Its schema and the console drawer still described the field as "a regexp matched against the device name", and the drawer rendered the value between slashes, which reads as a regexp literal and so carries the substring reading the fix removes. The placeholder taught the anchors as the way to get the obvious meaning; under MatchPattern they are redundant, so it now shows the pattern a reader would write. The manual pages arrived after that pass and describe the same three selectors from the operator's side, so they state it too, each with the example that separates the two readings: "staging" covers the device named staging and not staging-db, "root" authorizes the login root and not notroot.
|
Claude finished @otavio's task in 2m 36s —— View job Code Review CompleteReviewed 14 files across code quality, security, testing, language patterns, and architecture — no new issues found. The code looks good as-is. The one substantive change — deleting To request another review round, comment |
|
Documentation preview: https://31d11f38.shellhub-docs.pages.dev |
1 participant
Companion to #7018, which anchors the access rule matchers. That PR changes the behaviour; this one
changes everything that describes it.
The API specification and the console called these fields "regexps" and stopped there, which is
what leads an operator to write
stagingand expect the staging host. Anchoring is the part theyhave to know, so it is now stated where the field is described rather than left to be discovered
from behaviour.
What changes
API specification —
publicKeyFilterRequest,publicKeyFilterResponse,publicKeyUsername,accessPolicyFilterResponse,firewallRulesRequest,firewallRulesResponse.Console — the public key, access policy and firewall rule drawers. The access policy drawer
also rendered the pattern between slashes, which reads as a regexp literal and so carries the
substring reading; and its placeholder taught
^prod-.*$, where the anchors are now redundant.Manual —
access-policies,policy-reference,firewall-rulesandpublic-keysunder/manage/access-control, each with the example that separates the two readings:stagingcoversthe device named
stagingand notstaging-db;rootauthorizes the loginrootand notnotroot.Also drops
pkg/models/firewall.go.FirewallFilter,FirewallRuleFields,FirewallRuleandFirewallRuleUpdatehad no caller in either repo — firewall rules are an enterprise feature andthe live types are cloud's own. Every module still builds without it, which is the evidence it was
dead.
Merge order
Merge after #7018. The wording here describes anchored matching, which that PR introduces.