Correct docs for current access rules

Author: vossie

README.md

@@ -77,6 +77,9 @@ No pairing. No cloud dependency.
 - **User-managed access**
   Built-in local users with super-admin, admin, and user roles plus per-user API keys.
 
+- **Workspace access controls**
+  Public, password-protected, and explicit-user workspaces. Admins and super-admins can manage restricted workspaces, but user passwords never override workspace passwords.
+
 ---
 
 ## How it compares

SECURITY.md

@@ -7,5 +7,7 @@ DassieDrop is designed for trusted local networks.
 - If you need remote access, put it behind a reverse proxy with TLS and require user login.
 - New installs create a local super-admin user named `admin` with password `password`; change it after first login.
 - Authenticator app codes can be enabled per user for an extra login factor.
+- API automation uses per-user `X-API-Key` values. Browser login passwords are not API keys.
+- Workspace passwords are separate from user passwords. Admin and super-admin passwords do not unlock password-protected workspaces.
 - Files and messages expire after 24 hours by default unless the workspace policy says otherwise.
 - Passwords and API keys are stored as salted hashes, not plaintext.

dassiedrop/openapi.yaml

@@ -126,14 +126,19 @@ paths:
     delete:
       tags: [Workspaces]
       summary: Delete a workspace
-      description: Only workspace managers can delete workspaces. The default workspace can only be deleted by a super-admin user.
+      description: |
+        Only workspace managers can delete restricted workspaces. Workspace owners,
+        admins, and super-admin users do not need to provide the workspace password
+        when deleting a password-protected or explicit-access workspace. The default
+        workspace can only be deleted by a super-admin user.
       security:
         - sessionCookie: []
         - apiKeyAuth: []
       parameters:
         - $ref: '#/components/parameters/WorkspaceIdPath'
       requestBody:
         required: false
+        description: Optional legacy password payload. Authorized workspace managers do not need this.
         content:
           application/json:
             schema:

docs/api-usage.md

@@ -106,8 +106,11 @@ curl -X POST \
 ## Notes
 
 - The API is intended for local-network use.
+- `X-API-Key` must be a user's configured API key. A browser login password is not an API key.
+- Browser session cookies can also authenticate API requests, but cookie-backed `POST` and `DELETE` requests must include the page's `X-CSRF-Token`; `X-API-Key` requests do not need CSRF.
 - Use `X-Workspace` or `workspace` when targeting a non-default workspace.
+- Password-protected workspaces require `X-Workspace-Password` when selected by API header or query parameter. Admin and super-admin user passwords do not override workspace passwords.
 - Workspace names and usernames must be unique after normalisation.
 - Workspace access modes are `public`, `password`, and `explicit`.
-- For explicit-access workspaces, API clients can authenticate with a user's `X-API-Key`; the key's user must be the workspace owner or included in the workspace `explicit_usernames`.
+- For explicit-access workspaces, API clients can authenticate with a user's `X-API-Key`; the key's user must be the workspace owner or included in the workspace `explicit_usernames`. Admins and super-admins can manage access, but they must add themselves before entering an explicit workspace.
 - If you expose DassieDrop externally, put it behind proper TLS and access controls.

docs/bash-api.md

@@ -28,6 +28,8 @@ Protected workspaces can also use:
 
 - `X-Workspace-Password: <workspace-password>`
 
+User login passwords do not work as workspace passwords. Admin and super-admin users can manage restricted workspaces, but entering a password-protected workspace still requires the workspace password. For explicit-access workspaces, admins and super-admins can add themselves through access management before entering.
+
 List workspaces:
 
 ```bash
@@ -233,24 +235,30 @@ curl -sS \
   http://127.0.0.1:8000/api/share-text
 ```
 
-If you still want browser-style session auth from bash, you can log in first and reuse the session cookie:
+If you still want browser-style session auth from bash, you can log in first, fetch a page to read the CSRF token, and reuse both the session cookie and `X-CSRF-Token`:
 
 ```bash
 curl -sS -c cookies.txt \
   -H 'Content-Type: application/json' \
   -X POST \
   -d '{"username":"admin","password":"password"}' \
   http://127.0.0.1:8000/login
+
+CSRF_TOKEN="$(
+  curl -sS -b cookies.txt http://127.0.0.1:8000/ \
+    | sed -n 's/.*name="dassiedrop-csrf-token" content="\([^"]*\)".*/\1/p'
+)"
 ```
 
-Then pass `-b cookies.txt` on later requests:
+Then pass both values on later cookie-authenticated mutation requests:
 
 ```bash
 curl -sS -b cookies.txt \
   -H 'Content-Type: application/json' \
+  -H "X-CSRF-Token: $CSRF_TOKEN" \
   -X POST \
   -d '{"text":"hello again"}' \
   http://127.0.0.1:8000/api/share-text
 ```
 
-`X-API-Key` is for authenticated API routes. LAN links under `/s/{SHORT-CODE}` do not use `X-API-Key`; use `X-Access-Password` there only when a password is required.
+For automation, prefer `X-API-Key`; it does not need CSRF. User passwords are only for browser login, not API authentication. LAN links under `/s/{SHORT-CODE}` do not use `X-API-Key`; use `X-Access-Password` there only when a password is required.

docs/developer-guide.md

@@ -36,7 +36,8 @@ Rules:
 
 - Update `VERSION` when preparing a user-visible release change.
 - The UI header reads from `VERSION` unless `APP_VERSION` is provided in the environment.
-- The Ubuntu install script deploys the `VERSION` file and also supports `APP_VERSION` override in the service environment.
+- Static asset URLs use the app version plus an asset-content hash, so browsers pick up changed JavaScript and CSS without requiring a display-version bump for every internal fix.
+- The Ubuntu and CentOS Stream install scripts deploy the `VERSION` file and also support `APP_VERSION` override in the service environment.
 
 ## Main Branch Release Rule
 

docs/installation.md

@@ -92,7 +92,7 @@ HTTPS_SELF_SIGNED_HOST=192.168.1.24
 On a new installation DassieDrop creates a super-admin user named `admin` with password `password`.
 Change that password from the Users page after first login.
 
-Super-admin users can manage all local user accounts. Admin users can access any workspace. Regular users can access public workspaces, password-protected workspaces with the password, and explicit-access workspaces they have been granted.
+Super-admin users can manage all local user accounts. Admin and super-admin users can manage restricted workspace access and passwords, but they still need the workspace password to enter a password-protected workspace and must grant themselves access before entering an explicit-access workspace. Regular users can access public workspaces, password-protected workspaces with the workspace password, and explicit-access workspaces they have been granted.
 
 Users can enable an optional authenticator app from their own edit-user page. DassieDrop uses standard TOTP codes, so apps such as Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden, and Aegis can scan the displayed QR code or add the displayed secret manually. Super-admin users can disable authenticator protection for any user if someone loses access to their authenticator device.
 
@@ -374,6 +374,24 @@ curl -fsSL https://raw.githubusercontent.com/vossie/DassieDrop/master/scripts/gi
 
 In `--silent` mode, the installer keeps optional prompts disabled and uses default values.
 
+Uninstall the Ubuntu service from a checked-out repo:
+
+```bash
+sudo bash ./scripts/uninstall-ubuntu-service.sh
+```
+
+Or uninstall directly from GitHub:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/vossie/DassieDrop/master/scripts/uninstall-ubuntu-service.sh | sudo bash
+```
+
+Remove the uploaded data and service user too:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/vossie/DassieDrop/master/scripts/uninstall-ubuntu-service.sh | sudo REMOVE_DATA=1 REMOVE_USER=1 bash
+```
+
 Use the Ubuntu service install for a native `systemd` deployment. Use Docker for a portable container runtime.
 
 ## Install On CentOS Stream From GitHub
@@ -423,8 +441,20 @@ Uninstall the CentOS Stream service:
 sudo bash ./scripts/uninstall-centos-stream-service.sh
 ```
 
+Or uninstall directly from GitHub:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/vossie/DassieDrop/master/scripts/uninstall-centos-stream-service.sh | sudo bash
+```
+
 Remove the uploaded data and service user too:
 
 ```bash
 sudo REMOVE_DATA=1 REMOVE_USER=1 bash ./scripts/uninstall-centos-stream-service.sh
 ```
+
+Directly from GitHub:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/vossie/DassieDrop/master/scripts/uninstall-centos-stream-service.sh | sudo REMOVE_DATA=1 REMOVE_USER=1 bash
+```

docs/openapi.yaml

@@ -126,14 +126,19 @@ paths:
     delete:
       tags: [Workspaces]
       summary: Delete a workspace
-      description: Only workspace managers can delete workspaces. The default workspace can only be deleted by a super-admin user.
+      description: |
+        Only workspace managers can delete restricted workspaces. Workspace owners,
+        admins, and super-admin users do not need to provide the workspace password
+        when deleting a password-protected or explicit-access workspace. The default
+        workspace can only be deleted by a super-admin user.
       security:
         - sessionCookie: []
         - apiKeyAuth: []
       parameters:
         - $ref: '#/components/parameters/WorkspaceIdPath'
       requestBody:
         required: false
+        description: Optional legacy password payload. Authorized workspace managers do not need this.
         content:
           application/json:
             schema:

templates/help.html

@@ -181,7 +181,8 @@ <h3>Basic setup</h3>
         <pre class="help-code"><code>curl -sS -O "$API_HOST/openapi.yaml"</code></pre>
 
         <p>If the app is protected, send your automation secret as:</p>
-        <pre class="help-code"><code>-H 'X-API-Key: your-api-key-or-access-code'</code></pre>
+        <pre class="help-code"><code>-H 'X-API-Key: your-user-api-key'</code></pre>
+        <p>User passwords are only for browser login. They are not API keys and they do not unlock workspace passwords.</p>
 
         <h3>Share text</h3>
         <p>Share a text snippet:</p>
@@ -220,7 +221,7 @@ <h3>Share text</h3>
         <p>Share text into a protected workspace:</p>
         <pre class="help-code"><code>curl -sS \
   -H 'Content-Type: application/json' \
-  -H 'X-API-Key: your-api-key-or-access-code' \
+  -H 'X-API-Key: your-user-api-key' \
   -H 'X-Workspace: ops-desk' \
   -H 'X-Workspace-Password: workspace-secret' \
   -X POST \
@@ -257,7 +258,7 @@ <h3>Share files</h3>
 
         <p>Share a file into a protected workspace:</p>
         <pre class="help-code"><code>curl -sS \
-  -H 'X-API-Key: your-api-key-or-access-code' \
+  -H 'X-API-Key: your-user-api-key' \
   -H 'X-Workspace: ops-desk' \
   -H 'X-Workspace-Password: workspace-secret' \
   -X POST \
@@ -271,14 +272,14 @@ <h3>Using API auth</h3>
         <p><strong>Text example with API auth</strong></p>
         <pre class="help-code"><code>curl -sS \
   -H 'Content-Type: application/json' \
-  -H 'X-API-Key: your-api-key-or-access-code' \
+  -H 'X-API-Key: your-user-api-key' \
   -X POST \
   -d '{"text":"hello again"}' \
   "$API_HOST/api/share-text"</code></pre>
 
         <p><strong>File example with API auth</strong></p>
         <pre class="help-code"><code>curl -sS \
-  -H 'X-API-Key: your-api-key-or-access-code' \
+  -H 'X-API-Key: your-user-api-key' \
   -X POST \
   -F 'file=@./example.txt' \
   "$API_HOST/api/share-file"</code></pre>
@@ -350,9 +351,9 @@ <h3>Deleting a workspace</h3>
         <ul>
           <li>Open the workspace picker and find the workspace you want to remove.</li>
           <li>Click <strong>Delete</strong>.</li>
-          <li>If the workspace is protected, enter the workspace password to confirm deletion.</li>
+          <li>Confirm the prompt. Workspace owners, admins, and super-admin users can delete restricted workspaces without entering the workspace password.</li>
         </ul>
-        <p>The default workspace cannot be deleted.</p>
+        <p>The default workspace can only be deleted by a super-admin user.</p>
 
         <h3 id="sharing-text">Sharing text</h3>
         <ol>

templates/user_edit.html

@@ -53,7 +53,7 @@ <h2>Edit User</h2>
         <label class="settings-field" for="editUserPassword">
           <span class="settings-label-row">
             <span>Password</span>
-            <span class="settings-help" tabindex="0" data-tooltip="Leave blank to keep the current password. Root and admin passwords can unlock protected workspaces.">?</span>
+            <span class="settings-help" tabindex="0" data-tooltip="Leave blank to keep the current password. User passwords do not unlock workspace passwords.">?</span>
           </span>
           <div class="password-field-wrap">
             <input id="editUserPassword" class="inline-input settings-input" type="password" autocomplete="new-password" placeholder="New password">
@@ -77,7 +77,7 @@ <h2>Edit User</h2>
         <label class="settings-field" id="editUserRoleField" for="editUserRole">
           <span class="settings-label-row">
             <span>Role</span>
-            <span class="settings-help" tabindex="0" data-tooltip="User can access unprotected or password-known workspaces. Admin can access any workspace. Super-admin can also manage all users.">?</span>
+            <span class="settings-help" tabindex="0" data-tooltip="User can access public, password-known, and granted explicit workspaces. Admin can manage workspace access. Super-admin can also manage users.">?</span>
           </span>
           <select id="editUserRole" class="inline-input settings-input">
             <option value="user">user - password-protected workspace access</option>