专辑导出的流程中的签名功能实现, 包含签名申请, 签名申请的受理, 签名授权的导出, 签名授权的导入等功能。 #115
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Follow instructions in openspec-proposal.prompt.md. 现在让我们为导出专辑的流程添加新的步骤 此步骤的添加旨在为键音专辑添加响应的版权信息 我们需要展示一个供用户选择签名的对话框, 可选的签名使用的就是我们签名管理页面的数据, 当然, 我们的选择对话框同样支持调起创建签名的对话框, 以方便用户在没有签名的时候进行创建, 以及想要通过新的签名对专辑签名时方便创建。 我的想法是, 我们仅提供 ui 和前端的交互流程, 具体逻辑不需要实现, 后续我来自己写, 接下来告知你我的整体规划 首先, 用户点击导出按钮后会产生一个对话框, 用于给键音专辑的创建/修改者选择是否需要签名, 仅没有任何签名的专辑导出时允许选择不需要签名, 否则每次修改必须留下签名痕迹。 若是没有任何签名的专辑进行导出(或者说原创作者进行导出), 允许选择"二次创作必须通过当前签名作者授权"的选项(默认是取消勾选的), 此时二次导出或多次导出的人在导出前必须经过授权授权对话框导入授权文件后(原作者联系方式会在此处展示), 才可打开选择签名的对话框。 勾选"二次创作必须通过当前签名作者授权"的选项后, 必须留下个人联系方式, 此联系方式文本会随签名信息一同加入导出的键音专辑的配置中。 请仔细思考, 帮我规划ui及交互逻辑, 你就当你是一个懂前端的ui/ux设计师就好了, 请尽情发挥, 保证ui实现和ui交互流程可供我验收就好, 我会在验收后依次补全所有核心逻辑和澄清一切细节
Follow instructions in openspec-apply.prompt.md. 规格看起来不错, 请帮我实现这些规格任务
add-album-export-signature-flow规格的ui和交互逻辑的实现不够完整, 需要做变更
* 签名策略与要求的对话框功能不清晰, 需要拆分为更详细的对话框工作流程
* 首先是要不要展示签名确认对话框
* 如果是没有任何签名的专辑进行导出, 我们会先弹出确认签名对话框, 供用户确认所导出的键音专辑是否需要签名
* 如果用户选择了不需要签名, 则直接触发原始导出流程即可, 不涉及任何我们新增的关于签名的逻辑。
* 如果用户选择了需要签名则进入正常签名选择流程的对话框
* 如果是有过至少一个签名的键音专辑, 不会弹出签名确认对话框
* 签名授权对话框是否展示 (由于我们只是实现ui及交互逻辑, 因此现阶段无法检验真实专辑配置, 我能想到的测试方式就是你额外实现一个临时的按钮用于我查验此功能)
* 若要导出的专辑已经有签名并且选择了"二次创作必须通过专辑原作者授权"的选项则展示。
* 否则不展示
* 签名选择对话框是否展示
* 只在没有任何签名的专辑在导出时选择了 无需签名 选项后不需要展示
* 如果是没有任何签名的专辑在导出时选择了需要签名, 则会在弹出签名选择对话框前, 先弹出一个二次创作是否需要签名作者授权的对话框, 供用户确认是否需要授权(默认无需授权, 也是此软件推荐的做法), 之后再弹出签名选择对话框
* 如果是有至少一个签名且原始签名作者勾选了二次创作需授权的专辑在进行导出流程, 则会先展示签名授权对话框, 确认授权通过后才会进一步弹出签名选择对话框
* 二次创作是否需要签名作者授权的对话框的内容逻辑
* 若用户点击授权, 则会发起一个二次确认的对话框, 提示此操作可能影响当前专辑的传播, 即使不选择此项也不影响键音专辑中对原始作者的定位信息, 若用户检查授权, 则勾选成功后会有一个必填的授权联系方式的对话框供用户填写, 然后进入签名选择的对话框。
* 选择签名对话框中, 现如今的创建签名区域太大了, 用一个带提示的小按钮就行, 需要能真实触发创建签名的真实逻辑对话框(这个真实逻辑已经存在的可以直接使用的), 签名搜索 的功能值针对签名名称进行筛选
* 请在完成时留有足够清晰的注释, 以便后续真实逻辑的添加以及向验收人员说明。
目前已有的 `切换: 签名且需要授权`的临时切换按钮, 可以拆分并升级为一个专用有为测试模拟交互逻辑环境的对话框, 以供我检验ui与核心交互体验 其中, 我们模拟的专辑环境如下: * 当前专辑是否有签名 * 当前专辑是否选择了二次导出需要授权的选项 且我们的测试需要适配到整个核心交互流程中, 并通过详细注释说明, 以便于后续真实逻辑的实现
* 启用授权的影响的对话框中, 内容文本"启用“二次创作需授权”将限制他人在未获得授权时进行导出或修改，可能影响专辑的传播。但即使不启用，导出文件中仍会保留原作者信息。是否继续？"可以简化下, 且限制仅为导出限制, 本地修改的使用是不限制的, 不要"或修改", 并且整体i18n的文本组织优化下表达。 此外, 不需要放弃启用按钮, 只保留返回和我已知晓并继续两个按钮即可。 * 展示授权作者联系方式和选择授权文件的对话框i18n没有保证好中英文, 请改善这个问题 * 填写授权联系方式的文本框, 最好让邮箱为必填项目, 其它的(社交媒体, 官网等做为附加项, 可填可不填) 请按照我的需求, 继续优化ui即交互逻辑
目前导出专辑的签名流程中 的ui和交互逻辑的 新增和修改的代码文件有些乱, 我认为在components目录下, 可以将它们移动到一个子目录中, 用于表示这些组件是用于键音专辑页面导出流程的(也就是给这些组件分类) 至于composables/useExportSignatureFlow.ts这个文件, 就更让我摸不着头脑了, 只知道有用, 但不知道是干嘛的, 或许你可以通过在文件开头增加注释来向我解释其用途, 是用于临时保证ui交互的, 还是说要进入生产流程的 总之, 我希望整体架构和目录结构是人为可控的, 目前有很多不清晰的地方, 请修改目录结构是整体阅读体验更加清晰, 并通过文件注释和修改openspec规范来帮我澄清
我们的目录仍有不合理性, 请继续演进
* composables/useExportSignatureFlow.ts这个文件似乎放到components/export-flow/ 目录下更为合适, 或者你认为的更合适的地方, 请在修改后告知我
* 我注意到有个组件文件似乎存在报错
[{
"resource": "/d:/safe/KeyTone/frontend/src/components/export-flow/ExportSignatureFlowContainer.vue",
"owner": "typescript",
"code": "2307",
"severity": 8,
"message": "找不到模块“@/composables/useExportSignatureFlow”或其相应的类型声明。",
"source": "ts-plugin",
"startLineNumber": 81,
"startColumn": 40,
"endLineNumber": 81,
"endColumn": 78,
"origin": "extHost1"
}]
- 归档增强签名选择器样式（签名选择对话框样式与交互优化） - 归档重构签名选择器（签名选择对话框 UI 并接入真实数据） - 更新导出流程规范，新增 10 项需求 - 重新组织规范目录结构（album-export -> export-flow） - 所有实现均通过端到端测试
但逻辑暂为处理完全, 仍需在后续的使用体验中进一步进行验证。 修改了 LoadConfig 以处理 JSON 解析和解密回退。 增强了 WriteConfig 以原子性地重新加密源文件。 引入了 API 端点 POST /encrypt_album_config 用于加密相册配置。 更新了配置加载逻辑，以识别加密格式并处理遗留的十六进制密码。(此遗留不存在, 因为此实现未做任何提交且未发任何版本) 添加了调试 CLI 工具，用于以原始和解密格式打印配置。 在 TESTING.md 和 README 中文档化了新的加密功能和使用方法。 实现了加密配置的核心存根元数据处理。 添加了加密和解密过程的单元测试。 确保了与遗留十六进制密码格式的向后兼容性。
…动重新加密并处理 UUID 变更。
…改并扩展导出流程中无需签名的选项以支持无签名授权场景。
…”的选择，并始终保护原始作者的授权元数据。 具体bug需求修复提示详情见内容区。 再次导出签名时, 仍存在诸多bug, 请一一解决: 1. 若再次导出时选择的签名, 是首次导出者的签名, 则不应该因为更新而造成 首次导出者签名内部 代表首次导出者的authorization字段的消失。(或者说应该仅更新签名专属的name, intro, cardImagePath字段) 2. 若选择已有的签名会提示用户 取消, 不更新, 更新 三个选项, 但目前, 不更新按钮的选择也会造成签名的相关字段被更新。 或者说, 不管是不是对于首次导出作者的签名的更新, 只要保证对于签名信息的更新逻辑 仅更新 name, intro, cardImagePath 等签名信息相关字段, 而不是针对整个uuid对应的对象就好了。(当然, 这只是我对于修复以上问题的浅显看法, 具体实施方案你来仔细思考后自行决定即可) 请确保在代码和规范中同步进行实现。 同步代码实际实现和规格文档时, 注意所涉及到的部分包含(spec.md, design.md, proposal.md, tasks.md), 而不只是spec.md 我这次提到的内容你要认真思考, 仔细揣摩我的提案, 对重要的点以及不清楚的点一一澄清后, 再开始变更
我们继续解决再次导出签名时, 存在的bug: * 若选择已有的签名会提示用户 取消,不更新, 更新三个选项, 但目前, 不更新按钮虽不会实际更改name,intro,cardImagePath等签名信息, 但会将涉及到变更的图片存入目录中, 这是一个问题 * 另外, 若选择已有的签名会提示用户 取消,不更新, 更新三个选项, 更新按钮虽然可以更新 name,intro,cardImagePath等签名信息, 但若涉及到 cardImagePath 的实际图片信息, 则并不会对旧图片进行删除操作(这会造成键音包的尺寸不可控, 请修复这个问题) 请确保在代码和规范中同步进行实现。 同步代码实际实现和规格文档时, 注意所涉及到的部分包含(spec.md, design.md, proposal.md, tasks.md), 而不只是spec.md 我这次提到的内容你要认真思考, 仔细揣摩我的提案, 对重要的点以及不清楚的点一一澄清后, 再开始变更
或许我们可以进一步的优化选择已有签名时的更新签名确认对话框的调用机制。 我们可以对所选签名和专辑内的同id签名中的详细字段进行对比, 只有实际发生变更时才展示更新签名确认对话框供用户选择是否更新, 毕竟如果签名完全一样且未发生变化却弹出是否更新提示有点反直觉。 当然, 对于图片信息的比对, 可以利用实际图片文件的sha256校验码进行。(不过我不知道这个校验码在我们的应用业务逻辑中, 能否作为比对依据) 请确保在代码和规范中同步进行实现。 同步代码实际实现和规格文档时, 注意所涉及到的部分包含(spec.md, design.md, proposal.md, tasks.md), 而不只是spec.md 我这次提到的内容你要认真思考, 仔细揣摩我的提案, 对重要的点以及不清楚的点一一澄清后, 再开始变更 请保持每一步的中文说明
…完善临界区的加锁范围, 避免其它意外的死锁与panic可能。
… 用户仅可选择已经被授权过的签名。
…导入授权"按钮以主动开启原本所谓的“授权门控”(实际上就是导入授权文件的对话框而已)
-实现了用于生成和解析授权请求的端点。 -添加了根据本地签名验证原始作者签名的功能。 -创建了用于生成和验证授权授予的端点。 -为授权过程中的特定用例引入了确定性加密。 -定义了用于处理授权文件的数据结构和加密密钥。 -增强的错误处理和日志记录，以便在授权操作期间更好地进行可追溯性。
…有效的。但github的release流程仍未验证, 后续需手动在github页面添加相应的环境密钥, 使得从代码仓库ci:cd部署的版本和本地版本密钥一致。 一定程度上提升用户签名的安全性, 但会带来开源构建使用的默认密钥和仓库私钥的不兼容问题, 但一切仍旧是开源的, 君子密钥罢了。
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.