Show an Edit command only to capable users and handle authorization changing before save.

Resolve current-user capabilities on the server. Pass canEdit for rendering. The API must still enforce content.update; a 403 during save disables editing and explains recovery.

An editor sees Edit; an ordinary user does not. Removing capability after page load makes the next save return 403 safely.

• Derive visibility from server session.
• Recheck on mutation.
• Handle 403 explicitly.
• Do not expose controls through role-name guesses.

UI capability checks improve clarity, not security. The mutation response remains authoritative because sessions and permissions change.

export default async function ContentPage({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const [content, user] = await Promise.all([loadContent(id), getCurrentUser()]);
  return <ContentView content={content} canEdit={user.capabilities.includes("content.update")} />;
}

async function saveChanges(input: UpdateContent) {
  const response = await fetch(`/api/content/${input.id}`, {
    method: "PUT", headers: { "content-type": "application/json" }, body: JSON.stringify(input)
  });
  if (response.status === 401 || response.status === 403) {
    setEditing(false);
    setNotice("Your access changed. Reload before continuing.");
    return;
  }
  if (!response.ok) throw new Error("Save failed");
}

The server-rendered page avoids a flash of unauthorized controls. API authorization protects direct and stale-client requests.

• Capability changes after render.
• Session expires.
• Content becomes locked.
• User opens two tabs.

• Test hidden UI and direct API denial.
• Simulate 403 during save.
• Avoid snapshot-only tests.

• Treating hidden buttons as security.
• Using broad roles instead of capabilities.
• Ignoring stale permission changes.
• Showing a generic crash on 403.