中午收到同事微信，说 Airpub.io 首页几个图片被改写了，应该是前端暴露了又拍云表单上传密钥导致的。
我躺在床上琢磨这个事情，心想还是有闲的蛋疼的程序员做了。所以大概谈谈为什么 Airpub 要这么设计，以及如何规避这种事情的发生:
1. 为何如此设计？
在刚开始写 Airpub 时，我们考虑要为 markdown 编辑器构建一种非常好的图片上传用户体验，同时又不需要用户自建后端服务，或依赖本地工作流。这种方式的工具其实本身面临着很大的安全风险，如果不暴露又拍云的表单密钥，就意味着图片上传的签名需要手动依赖工作流进行构造，也违背了这工具所设计的初衷。
2. 图片如何被复写？
Airpub 0.2.x 所依赖的 upyun 组件使用的文件最后上传路径是文件名，因此这个文件名很容易使用已经暴露的密钥重新上传导致覆盖。
在 Airpub 0.3.x 的版本中采用新版 upyun 模块，使用文件的 md5 作为最终上传路径，因此也就没那么容易被覆盖。但还是可以通过复制此文件的 md5 的方式，写死上传最终文件地址，上传新的图片覆盖掉此图片。也就是说，一旦暴露了表单密钥，任何文件都有可能会被覆盖。
3. 如何避免这种情况发生？
我们考虑了两种方式：
- Airpub 提供一个工作流工具，此工具将提供一个命令行界面，根据用户提供的表单密钥一次性生成签名，然后将此签名暴露给前端组件。
- 在非编辑的情况下，经常性地在又拍云后台修改表单密钥，确保此密钥及时更新，不被泄露。在编辑文章时，临时将正确的密钥进行替换。
另外， Airpub 已将编辑器拆分出核心代码，另起项目 EditorNinja，拆分后的项目最新稳定版本已发布 v0.3.2。今后，编辑器相关的功能，都会在 EditorNinja 项目进行维护。我们欢迎大家给 Airpub 挑错，但更欢迎大家以提 issue 的方式告诉我们问题在哪儿，让这个项目越来越完善。
欢迎 Star & fork:
https://github.com/duoshuo/airpub
EditorNinja，可便捷拓展，支持实时代码高亮的 markdown 编辑器：
https://github.com/airpub/ninja
我躺在床上琢磨这个事情，心想还是有闲的蛋疼的程序员做了。所以大概谈谈为什么 Airpub 要这么设计，以及如何规避这种事情的发生:
1. 为何如此设计？
在刚开始写 Airpub 时，我们考虑要为 markdown 编辑器构建一种非常好的图片上传用户体验，同时又不需要用户自建后端服务，或依赖本地工作流。这种方式的工具其实本身面临着很大的安全风险，如果不暴露又拍云的表单密钥，就意味着图片上传的签名需要手动依赖工作流进行构造，也违背了这工具所设计的初衷。
2. 图片如何被复写？
Airpub 0.2.x 所依赖的 upyun 组件使用的文件最后上传路径是文件名，因此这个文件名很容易使用已经暴露的密钥重新上传导致覆盖。
在 Airpub 0.3.x 的版本中采用新版 upyun 模块，使用文件的 md5 作为最终上传路径，因此也就没那么容易被覆盖。但还是可以通过复制此文件的 md5 的方式，写死上传最终文件地址，上传新的图片覆盖掉此图片。也就是说，一旦暴露了表单密钥，任何文件都有可能会被覆盖。
3. 如何避免这种情况发生？
我们考虑了两种方式：
- Airpub 提供一个工作流工具，此工具将提供一个命令行界面，根据用户提供的表单密钥一次性生成签名，然后将此签名暴露给前端组件。
- 在非编辑的情况下，经常性地在又拍云后台修改表单密钥，确保此密钥及时更新，不被泄露。在编辑文章时，临时将正确的密钥进行替换。
另外， Airpub 已将编辑器拆分出核心代码，另起项目 EditorNinja，拆分后的项目最新稳定版本已发布 v0.3.2。今后，编辑器相关的功能，都会在 EditorNinja 项目进行维护。我们欢迎大家给 Airpub 挑错，但更欢迎大家以提 issue 的方式告诉我们问题在哪儿，让这个项目越来越完善。
欢迎 Star & fork:
https://github.com/duoshuo/airpub
EditorNinja，可便捷拓展，支持实时代码高亮的 markdown 编辑器：
https://github.com/airpub/ninja
3
Select Language