Skip to main content

Restrict a sensitive document

Jiandu's normal household library is shared. Use a restriction for an exception such as a private legal record or health document—not as a replacement for clear household membership.

:::caution Native API workflow The browser does not yet expose document access-policy administration. The native API and the tested Compose helper implement the workflow. If you cannot repeat the two-account denial check, do not rely on per-document restrictions yet. :::

Run the evidence-producing drill​

The helper is for the repository's promoted examples/docker-compose topology. It requires Bash, Docker Compose, curl, and jq, plus:

  • a running, claimed stack at https://jiandu.localhost;
  • a named local Administrator account; and
  • the ID of a currently shared, non-sensitive test document.

From the repository root, run:

./examples/docker-compose/restrict-document-drill.sh

The helper copies Caddy's local CA into a mode-private temporary directory and verifies TLS; it never uses --insecure. Passwords are read without terminal echo, confirmed before use, passed to curl through standard input, and removed from shell variables after the test sessions exist.

It then performs this complete check:

  1. Sign in as the Administrator and resolve the built-in Member role.
  2. Confirm that the chosen document exists, has a strong revision ETag, and is currently shared.
  3. Create two ordinary test Members.
  4. Change the document to restricted, with the Administrator as policy manager.
  5. Give only the first test Member the viewer document role.
  6. Prove that Member receives 200 for both detail and original content.
  7. Prove that the other Member receives 404 for both direct URLs—the same response as an unknown document, so the restriction does not disclose existence.

Success ends with:

Restriction drill passed: allowed detail/original 200; denied detail/original 404.
Cleanup will restore shared visibility and suspend both test Members.

An EXIT trap also runs after an error or interrupt. It discovers partially created resources where possible, revokes the test grant, restores shared visibility, suspends both test Members, deletes the three sessions, and removes temporary response and credential files. A cleanup failure turns an otherwise successful run into a failure and names the manual action still required.

Apply the result to a real exception​

Repeat the policy change through a reviewed API client, but do not reuse the drill's disposable accounts. Choose the least-capable document role:

RoleIntended access
viewerRead detail, previews, and the original.
editorViewer access plus permitted document changes.
managerEditor access plus administration of this document's policy and grants.

Grant access to a named principal or authorization group. Prefer a group when the same boundary applies to several documents, and give every restricted document an accountable policy manager. Time-bound grants are supported through expiresAtMs; an expired grant is not active access.

Use the generated operations for the exact request and response contract:

Record the business reason, manager, recipients, and review date outside the document itself. Run the denied-account check again after any role, group-membership, reverse-proxy, or identity-provider change that could affect authorization.

Roll back safely​

Revoke obsolete grants before returning a document to shared. Confirm the shared response with an ordinary Member, then suspend or remove any disposable test identities. If the helper reports an incomplete cleanup, keep the document ID and named principal IDs in the incident record until an Administrator completes each printed action.

Next: Audit document lifecycle behavior and include this test in the deployment checklist.

Last updated on