- 新增许可证服务器 (license-server/) - 新增 Agent 部署模块 (flnxi-agent/) - 添加许可证验证和激活页面 - 添加 Harbor 镜像同步脚本 - 更新素材系统支持许可证验证
15 KiB
Requirements Document
Introduction
本文档定义了 FLNXI 素材系统的许可证管理系统需求。该系统旨在实现软件的商业化分发,支持免费版、标准版和Pro版三个版本,通过联网验证和硬件指纹绑定实现防破解保护。系统包含两个主要部分:部署在客户端的许可证验证模块,以及部署在中央服务器的许可证验证服务和客户管理后台。
Glossary
- License(许可证): 授权客户使用软件特定版本和功能的凭证
- License Key(许可证密钥): 用于激活许可证的唯一字符串,格式为 XXXX-XXXX-XXXX-XXXX
- Hardware Fingerprint(硬件指纹): 基于客户服务器硬件特征生成的唯一标识符
- License Server(许可证服务器): 部署在 45.249.208.118 的中央验证服务
- Client Instance(客户端实例): 部署在客户 NAS/服务器上的 FLNXI 素材系统实例
- Heartbeat(心跳): 客户端定期向服务器发送的存活和验证请求
- Grace Period(宽限期): 网络断开后允许继续使用的时间窗口
- Admin Portal(管理后台): 用于管理客户和许可证的 Web 界面
- Code Obfuscation(代码混淆): 将源代码转换为难以阅读和理解的形式,增加逆向工程难度
- Agent(安装代理): 运行在客户 NAS 上的轻量级 Docker 容器,提供 Web 安装界面,帮助客户自助完成系统部署
- Semantic Versioning(语义化版本): 版本号格式为 v主版本.次版本.修订号(如 v1.2.3)
- Rollback(回滚): 将系统恢复到之前版本的操作
- Forced Update(强制更新): 必须完成才能继续使用系统的更新
- Optional Update(可选更新): 用户可自行决定是否执行的更新
Requirements
Requirement 1: 许可证版本定义
User Story: As a 系统管理员, I want to 定义不同版本的功能限制, so that 可以实现差异化的产品定价策略。
Acceptance Criteria
- THE License_Server SHALL support three license types: FREE, STANDARD, and PRO
- WHEN a license type is FREE, THE System SHALL enforce a maximum of 10 users
- WHEN a license type is FREE, THE System SHALL enforce a maximum of 100 materials
- WHEN a license type is FREE, THE System SHALL disable custom template functionality
- WHEN a license type is FREE, THE System SHALL disable advanced system settings
- WHEN a license type is FREE, THE System SHALL disable department isolation functionality
- WHEN a license type is STANDARD or PRO, THE System SHALL allow unlimited users and materials
- WHEN a license type is PRO, THE System SHALL enable intranet penetration functionality
Requirement 2: 许可证激活
User Story: As a 客户, I want to 使用许可证密钥激活系统, so that 可以解锁对应版本的功能。
Acceptance Criteria
- WHEN a user first accesses the system without activation, THE System SHALL display an activation page
- WHEN a user enters a valid license key, THE System SHALL send an activation request to the License_Server
- WHEN the License_Server receives an activation request, THE System SHALL validate the license key format and existence
- WHEN the license key is valid and not already activated, THE License_Server SHALL bind the license to the hardware fingerprint
- WHEN activation succeeds, THE Client_Instance SHALL store the license information locally
- WHEN a user chooses "free trial" without a license key, THE System SHALL activate as FREE version automatically
- IF the license key is invalid or already activated on another device, THEN THE System SHALL display an appropriate error message
- WHEN activation completes, THE System SHALL redirect to the main application
Requirement 3: 硬件指纹生成
User Story: As a 系统, I want to 生成稳定的硬件指纹, so that 许可证可以绑定到特定设备而不受常见硬件升级影响。
Acceptance Criteria
- THE System SHALL generate a hardware fingerprint using machine ID, hostname, and primary MAC address
- THE System SHALL NOT include RAM information in the hardware fingerprint
- THE System SHALL NOT include non-system disk information in the hardware fingerprint
- THE System SHALL generate a unique instance ID on first activation and store it persistently
- WHEN hardware components change, THE System SHALL use a weighted matching algorithm with a 60% threshold
- WHEN the fingerprint match score falls below 60%, THE System SHALL require re-activation
Requirement 4: 许可证验证
User Story: As a 系统, I want to 定期验证许可证状态, so that 可以确保只有合法用户使用付费功能。
Acceptance Criteria
- WHEN the system starts, THE Client_Instance SHALL verify the license with the License_Server
- WHILE the system is running, THE Client_Instance SHALL send heartbeat requests every hour
- WHEN the License_Server receives a verification request, THE System SHALL check license validity, expiration, and hardware fingerprint
- WHEN verification succeeds, THE License_Server SHALL return the current license configuration
- WHEN verification fails due to network issues, THE Client_Instance SHALL use cached license data
- WHEN the system operates offline, THE Client_Instance SHALL allow a grace period of 7 days
- IF the grace period expires without successful verification, THEN THE System SHALL enter read-only mode
Requirement 5: 功能限制执行
User Story: As a 系统, I want to 根据许可证类型限制功能, so that 免费用户无法使用付费功能。
Acceptance Criteria
- WHEN a FREE user attempts to create the 11th user, THE System SHALL block the operation and display an upgrade prompt
- WHEN a FREE user attempts to upload the 101st material, THE System SHALL block the operation and display an upgrade prompt
- WHEN a FREE user accesses custom template settings, THE System SHALL hide or disable the functionality
- WHEN a FREE user accesses department isolation settings, THE System SHALL hide or disable the functionality
- WHEN checking feature availability, THE System SHALL query the cached license configuration
- THE System SHALL display current usage statistics (users/materials count) in the settings page
Requirement 6: 客户管理后台
User Story: As a 平台管理员, I want to 管理所有客户的许可证, so that 可以进行销售和客户服务。
Acceptance Criteria
- THE Admin_Portal SHALL require authentication to access
- WHEN an admin views the dashboard, THE System SHALL display total customers count by license type
- WHEN an admin views the customer list, THE System SHALL display company name, license type, status, and expiration date
- WHEN an admin creates a new license, THE System SHALL generate a unique license key
- WHEN an admin upgrades a customer's license, THE System SHALL update the license type immediately
- WHEN an admin disables a license, THE System SHALL mark it as inactive and reject future verifications
- WHEN an admin resets hardware fingerprint, THE System SHALL allow the license to be activated on a new device
- THE Admin_Portal SHALL display usage statistics for each customer (user count, material count, last heartbeat)
Requirement 7: 异常检测
User Story: As a 平台管理员, I want to 检测许可证滥用行为, so that 可以防止盗版和许可证共享。
Acceptance Criteria
- WHEN the same license key sends heartbeats from multiple different hardware fingerprints within 24 hours, THE System SHALL flag it as suspicious
- WHEN suspicious activity is detected, THE Admin_Portal SHALL display an alert
- WHEN an admin reviews suspicious activity, THE System SHALL show the list of hardware fingerprints and their locations
- THE Admin_Portal SHALL allow admins to whitelist legitimate multi-device scenarios
Requirement 8: 许可证信息展示
User Story: As a 客户, I want to 查看当前许可证状态, so that 可以了解使用情况和到期时间。
Acceptance Criteria
- THE System SHALL display license information in the system settings page
- THE System SHALL show license type, activation status, expiration date, and feature availability
- THE System SHALL show current usage (user count, material count) compared to limits
- WHEN the license is about to expire within 30 days, THE System SHALL display a renewal reminder
- THE System SHALL provide a link to upgrade or renew the license
Requirement 9: 安全通信
User Story: As a 系统, I want to 确保许可证通信安全, so that 验证过程无法被篡改或伪造。
Acceptance Criteria
- THE System SHALL use HTTP with application-layer encryption for communication between Client_Instance and License_Server
- THE System SHALL encrypt request payloads using AES-256-GCM before transmission
- THE System SHALL sign all license data using RSA asymmetric encryption
- THE Client_Instance SHALL verify the signature of license data using the embedded public key
- THE System SHALL include timestamps in requests to prevent replay attacks
- IF signature verification fails, THEN THE System SHALL reject the license data and log the incident
- THE System SHALL support upgrading to HTTPS when SSL certificates are configured
Requirement 10: 数据持久化
User Story: As a 系统, I want to 安全存储许可证数据, so that 系统重启后无需重新激活。
Acceptance Criteria
- THE Client_Instance SHALL store license data in the database with encryption
- THE Client_Instance SHALL store the instance ID persistently across restarts
- THE License_Server SHALL store all customer and license data in a PostgreSQL database
- THE System SHALL backup license data regularly to prevent data loss
- WHEN license data is corrupted, THE System SHALL attempt to recover from the License_Server
Requirement 11: 代码混淆保护
User Story: As a 系统, I want to 对关键代码进行混淆处理, so that 增加逆向工程和破解的难度。
Acceptance Criteria
- THE Build_Process SHALL obfuscate license verification related source files during production build
- THE Build_Process SHALL obfuscate hardware fingerprint generation source files during production build
- THE Build_Process SHALL obfuscate cryptographic signature verification source files during production build
- THE Build_Process SHALL NOT obfuscate business logic components to maintain debuggability
- WHEN obfuscation is applied, THE System SHALL maintain identical functionality to non-obfuscated code
- THE Build_Process SHALL use control flow flattening and string encoding techniques
- THE Build_Process SHALL generate source maps separately for internal debugging purposes only
- WHEN the production build completes, THE System SHALL verify that obfuscated code executes correctly
Requirement 12: 自助安装(Agent 方案)
User Story: As a 客户, I want to 通过简单的方式自助部署和更新系统, so that 无需手动配置 Docker 命令,也不需要联系技术支持。
Acceptance Criteria
- THE System SHALL provide a lightweight Agent Docker image (flnxi/flnxi-agent) on Docker Hub for customers to download
- THE Agent image SHALL be compatible with mainstream NAS systems including Synology, QNAP, and fnOS
- WHEN the Agent container starts, THE Agent SHALL provide a Web-based management interface on port 9000
- THE Agent Web interface SHALL allow customer to configure system port (default 4320)
- THE Agent SHALL NOT perform license validation (license activation is handled by the material system on first startup)
- WHEN customer clicks install, THE Agent SHALL pull the FLNXI material system image from harbor.flnxi.com/flnxi/material/flnxi-material
- THE Agent SHALL create and start the FLNXI material system container with configured settings
- THE Agent Web interface SHALL display installation progress with clear status messages
- WHEN installation completes, THE Agent SHALL display the access URL for the system
- IF installation fails, THEN THE Agent SHALL display error details and provide retry option
- THE Agent SHALL provide system update functionality to pull and deploy latest version
- THE Agent Web interface SHALL display current system version and available updates
- THE Agent SHALL NOT collect or transmit any customer usage data
- THE Agent container SHOULD be kept running for future system updates
Requirement 13: 版本管理
User Story: As a 平台管理员, I want to 管理系统版本发布, so that 可以有序地向客户推送更新。
Acceptance Criteria
- THE System SHALL use semantic versioning format (vMAJOR.MINOR.PATCH) for all releases
- THE License_Server SHALL maintain version information including latest version and minimum required version
- WHEN a new version is released, THE Admin_Portal SHALL allow setting the minimum required version
- THE License_Server SHALL provide a version check API that returns latest version, minimum required version, and release notes
- THE System SHALL store version number in /app/VERSION.txt within the Docker image
- THE Harbor registry SHALL retain at least the 3 most recent versions for rollback purposes
Requirement 14: 系统更新
User Story: As a 客户, I want to 方便地更新系统到最新版本, so that 可以获得新功能和安全修复。
Acceptance Criteria
- WHEN the Agent checks for updates, THE Agent SHALL compare current version with latest version from License_Server
- WHEN an optional update is available, THE Agent SHALL display update notification with version number and release notes
- WHEN a forced update is required, THE System SHALL block access to main application until update is completed
- WHEN customer initiates update, THE Agent SHALL pull new image using Docker incremental layer download
- THE Agent SHALL display download progress and estimated time during update
- WHEN update completes, THE Agent SHALL restart the system container automatically
- IF update fails, THEN THE Agent SHALL automatically rollback to previous version
- THE Agent Web interface SHALL provide manual rollback option to any of the 3 most recent versions
Requirement 15: 更新回滚机制
User Story: As a 客户, I want to 在更新失败时自动恢复, so that 系统不会因为更新问题而无法使用。
Acceptance Criteria
- WHEN starting an update, THE Agent SHALL backup current container configuration
- WHEN starting an update, THE Agent SHALL rename current container instead of deleting it
- WHEN new container starts, THE Agent SHALL perform health check by calling /api/health endpoint
- WHEN health check fails within 60 seconds, THE Agent SHALL trigger automatic rollback
- WHEN rollback is triggered, THE Agent SHALL stop new container, restore backup container, and restart it
- WHEN rollback completes, THE Agent SHALL display message indicating rollback reason and restored version
- THE Agent Web interface SHALL allow manual rollback with version selection