Seafile Share Links and API Tokens Need Separate Lifecycle Reviews
Seafile combines libraries, roles, share links, and API access. A user can be allowed to create a public link without being an administrator, and an integration can hold an API token without needing every permission of the user who created it. Treating all access as "a Seafile user can share files" hides the differences that matter during an incident.
Roles set the ceiling
The Seafile role documentation describes built-in default and guest roles and configurable permissions such as generating share links and inviting guests. A role is a ceiling on what a user can initiate, but the library's own sharing policy and the link's permissions still matter. Review both the role and the object-level setting.
The seahub_settings.py documentation lists controls that force passwords on share or upload links and can require login before viewing a share link. Those settings are deployment policy. If they are disabled for compatibility, document the exception and compensating controls.
Links and tokens are different capabilities
A share link grants access to a selected library or folder, sometimes with a password or account requirement. An API token authenticates a program that may list libraries, upload content, or perform other operations allowed by the integration. A link leak can expose one shared object; a token leak can expose a broader automation scope.
Create separate tokens for backup, synchronization, publishing, and monitoring. Record their owner and review date. Use link passwords and expiry where the deployment supports them. Before moving content into an encrypted or restricted library, verify whether the link or token workflow remains valid.
Exposure evidence
A ZoomEye count-only query for app="Seafile" returned 42,136 results on 2026-11-08 using sub_type=all, page 1, and page size 1. The title query returned 57,575 and the body query 123,984. These are product-presence observations, not evidence that a library is public or that a share link is active.
Search link: ZoomEye application query
Review procedure
Generate a share link as a normal user and verify the forced-password and login requirements. Revoke it and confirm that the old URL fails. Create an API token for a non-admin account and test an operation outside its library. Change the user's role and verify that the effective authority changes without requiring a new token by accident.
Finally, reconcile the two inventories. Every active link should have an owner, object, expiry or review date, and password policy. Every API token should have a client, purpose, scope, and rotation date. The goal is to keep the convenient sharing path from becoming the forgotten path that bypasses the role model.
