之前拖了很长时间主要是卡在编辑器这块，主要因为是要实现一个外部存储挂载的服务。使用AJAX跨域上传到外部存储，只要两端沟通好没啥问题。可是考虑到一个情况，就是恶意提交。现在要把所有用户当成潜在的攻击者来防御，因为有些人闲得无聊会反复利用上传来搞垮服务器（这事我就干过）。

背景是网站服务器和存储服务器不能直接沟通，一是网络环境不稳定可能失败，二是PHP链接时间长可能引发程序崩溃，所有嫁接和验证都需要在客户端执行。如果是直接由网站生成HASH让客户端和存储端验证，就可能出现上面所说的情况，站长可以先上传，然后拦截HASH回调，造成文件在存储端大量堆积，网站端又没法检查出来。

经过一些沟通得到了一个相对稳妥的流程，可以解决这一问题：

0.网站端存储建立附件索引，所有附件对应唯一FID，这个索引是自动增量关系。对于存储端的操作只有增加、删除两种，修改等操作实际是删除旧文件并增加新文件。

1.用户请求了N个上传，服务器端生成唯一上传HASH（只可用于各FID文件上传），在附件数据中写入这些文件待上传状态。上传HASH有数量限制，根据用户权限设置。

2.用户利用该HASH向存储服务器发送请求，存储服务器检查是否有相同FID文件（防止重复上传），如果没有则开放上传接口。若上传成功则返回JSON，客户端将其暂时附加到待提交数据。

3.向网站端提交，检查数据库所有未完成状态的文件，比对客户端提交数据JSON是否一致。若不一致，可能为【客户端>网站端】恶意增加数据，后端进行拦截。

4.若没有JSON，可能是上传不成功或没有返回JSON，可能为【客户端>存储端】恶意上传文件，后端保持锁定状态不予保存。需要客户端重新向存储端提交上传检查，扫描后返回新的JSON再提交。（遗留问题：如果确实没上传成功？）

5.删除指令和上传相似，也是需要由服务器生成唯一删除HASH，将申请过删除HASH的文件设定为待删除状态。客户端利用此HASH向存储端发送删除指令，若成功则返回JSON。

6.提交时数据库检查待删除文件，若该文件没有JSON或比对失败，可能是【客户端>存储端】恶意删除文件，但希望数据库保留该文件状态冗余。此时数据库不予保存，需要客户端重新向存储端提交检查，确保文件已删除然后再保存。