企业官网建设流程全解析

如何用 copyparty 的 filekeys 为共享文件生成访问密钥，防止文件名暴力猜测

【免费下载链接】copypartyPortable file server with accelerated resumable uploads, dedup, WebDAV, SFTP, FTP, TFTP, zeroconf, media indexer, thumbnails++ all in one file项目地址: https://gitcode.com/GitHub_Trending/co/copyparty

当你用 copyparty 对外提供文件共享时，常见做法是只给访客g（get）权限：不开放目录列表，只接受文件的直接 URL。但这样一来，如果访问者知道服务器上大概放着什么文件，就可以靠猜文件名把文件下载走。copyparty 的 filekeys 功能（volflagfk）就是为此设计的：为每个文件生成一个随机的访问密钥，访问 URL 必须带上正确的密钥参数?k=...才能取到文件，猜文件名不再有意义。

filekeys 的工作原理

README 的 filekeys 一节说明了行为：

• volflagfk为该卷内所有文件生成 per-file accesskey。拥有完整读权限（r）的用户在浏览目录时，看到的文件 URL 会自动带上正确的 filekey?k=...；
• 只有g（get）权限的用户必须拿到带正确密钥的完整 URL 才能下载，否则得到 404；
• 密钥默认由 salt（全局参数--fk-salt）+ 文件系统路径 + 文件大小 + inode（Windows 上不含 inode）共同生成；
• 加上 volflagfka则生成"稍弱"的密钥（仅基于 salt + 路径），编辑文件后密钥不会失效；
• 权限wG（write + upget）允许用户上传文件并只拿回自己的filekey，看不到别人的上传。

salt 默认是自动生成的，存放在配置目录（$XDG_CONFIG_HOME下的 copyparty 配置中，见 docs/chungus.conf 中fk-salt的注释）。启动时加--show-fk-salt可以打印当前生效的 salt 值，方便核对。

配置方法：命令行参数

-v的语法是src:dst:perm:perm:...，volflag 写在权限段里。README 中给出的启用 filekeys 的示例：

python copyparty-sfx.py -v /mnt/ss:i:rw,u1:g:c,fk=4

逐项含义（以 README 为例的注释为准）：

• 把/mnt/ss挂载到 URL/i；
• 用户u1拥有rw，可以上传、浏览目录，并在浏览时看到生成的 filekeys；
• 其他用户只有g:c,fk=4：fk=4表示每个文件生成 4 字符的 accesskey；他们可以凭带密钥的完整 URL 访问文件，但无法浏览目录。

把g换成wG会得到另一种典型用法——任何人都能上传，并收到自己文件的"secret"链接（README complete examples 一节）：

python copyparty-sfx.py -e2dsa -v .::wG:c,fk=8

fk=8即 8 字符密钥。README 还给出了一个针对电子书服务的变体：某些客户端（例如 Moon+ Reader）下载封面图时不发送密码，会被服务器按失败密码封禁 IP，此时给未认证请求g权限并启用 filekeys 防猜名：-vbooks:books:r,ed:g:c,fk,opds。

配置方法：配置文件

配置复杂时用配置文件更合适。README 给出的例子（把/mnt/ss挂到/i，u1读写、其他所有人只能凭 URL 访问，每个文件 URL 附带 4 字符密钥）：

[/i] /mnt/ss accs: rw: u1 g: * # everyone can access files if they know the URL flags: fk: 4 # each file URL will have a 4-character password

仓库里的完整配置示例 docs/example.conf 展示了一个wG+fk的上传卷：

[/sharex] /home/ed/inc/sharex accs: wG: * # wG = write-upget = see your own uploads only rwmd: ed, k # read-write-modify-delete for users "ed" and "k" flags: e2d, d2t, fk: 4 # volflag "e2d" enables the uploads database, # "d2t" disables multimedia parsers (in case the uploads are malicious), # "dthumb" disables thumbnails (same reason), # "fk" enables filekeys (necessary for upget permission) (4 chars long)

注意注释说明：一行可以连写多个 volflag，因为只有最后一个 flag 携带参数值（e2d, d2t, fk: 4中4只属于fk）。

配置文件通过-c参数使用，也可以用环境变量（方便 docker 等场景）：

python copyparty-sfx.py -c foobar.conf # 或者 PRTY_CONFIG=foobar.conf python copyparty-sfx.py

验证 filekeys 是否生效

文档描述的行为本身就可以作为核对依据：

1. r权限用户：登录后浏览目录，文件链接末尾应带有?k=...参数（有r权限的人才能看到 filekeys）。
2. g权限用户或匿名访问者：直接请求不带密钥的文件 URL 应返回 404；拿到带正确?k=...的完整 URL 后才能下载。
3. wG上传场景：上传完成后，响应中会返回该文件的 filekey/直接链接（README 说明上传者"receivea working direct link in return"），把链接发给对方即可，对方无需登录。
4. salt 核对：启动时加--show-fk-salt，确认生效的 salt 与预期一致（例如 docker/systemd 环境下多处部署需要同一 salt 时）。
5. 调试：全局参数log-fk可指定一个正则，对路径匹配的文件记录其 filekey 参数（docs/chungus.conf 中的log-fk），默认未设置，适合排查特定目录的密钥问题。

限制与注意事项

以下边界都来自文档，配置前确认你的场景是否命中：

• 密钥会随文件变化：默认 filekey 基于大小 + inode 生成，文件被编辑后旧密钥失效。需要密钥在文件被编辑后仍然有效时，改用 volflagfka（略弱，仅 salt + 路径）；
• filekey 最长 72 字符（docs/changelog.md 中的限制说明）；
• m3u8 播放列表不支持 filekeys/dirkeys：播放列表里的曲目必须让听众本身拥有 read-access 或 get-access；
• h权限的例外：h权限下目录返回index.html，而index.html本身不需要 filekey 即可获取，其余文件仍然受密钥保护；
• 与 dirkeys 同开的版本要求：v1.20.17（2026-07-06）修复了一个漏洞——同一个卷同时启用 filekeys 和 dirkeys 时，一个有效的 filekey 可以被转换成 dirkey，从而获得所在文件夹的读权限。两者同用时请升级到 v1.20.17 或更新版本（见 docs/changelog.md）；
• dirkeys 场景：如果启用了 dirkeys（dk），README 建议同时启用 filekeys，否则通过 dirkey 进入的文件夹里的文件无法被直接外链。

配置完成并通过上述验证后，g权限的目录就是"无列表、凭链接取文件"的共享方式，文件名暴力猜测对访问没有任何帮助。

【免费下载链接】copypartyPortable file server with accelerated resumable uploads, dedup, WebDAV, SFTP, FTP, TFTP, zeroconf, media indexer, thumbnails++ all in one file项目地址: https://gitcode.com/GitHub_Trending/co/copyparty