Share-link policy enforcement — org ceiling, not just defaults (#62) #65
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/share-policy"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #62. First of the public-sector batch (#59 derived).
Settings store gains three enforced policy fields (all zero-value = today's behavior):
shareMaxExpiry(links may not outlive this; "" = no ceiling),shareRequirePassword,shareUploadsForbidden. Validation parity with the existing expiry field.Enforcement lives in
shareCreateright after decode — one chokepoint, so the web dialog, raw REST calls, and anything else hittingPOST /api/v1/sharesall obey it. Policy violations return 400 with apolicy:message.UI: Settings panel gets the three controls (with a clear "enforced" label vs the existing defaults); the share dialog hides expiry options beyond the ceiling (including "Never"), clamps the default, marks the password field required, and hides the upload checkbox when forbidden — the server remains the enforcement point.
Tests: all four rejection branches + compliant pass-through + zero-value/nil-settings permissiveness + settings validation. gofmt/vet/build/test +
node --checkon the embedded script green on the runner.