我正在开发一个用户加入“流”的项目.在流设置期间,创建流的人(流创建者)可以选择：
>将成员添加到流中的所有照片上传到我们的托管解决方案(S3)
>将成员添加到流中的所有照片上传到流创建者自己的DropBox身份验证文件夹
在未来我想添加更多存储提供商(如Drive,Onesky等)
关于如何解决这个问题,我有几个不同的问题.
>照片数据库中的结构应该是什么？我目前只有photo_url,但从数据的角度来看,使用预先签名的网址并且有不同的方式可以上传照片(s3,dropBox等),这是不容易的.
>如何存储每个存储提供程序的访问令牌？请记住,只会存储流创建者的access_token,并且流上的所有人都会在上传照片时共享该令牌
>我将在未来添加iOS和Web客户端,直接上传到存储提供商并绕过服务器以避免服务器负载过重
解决方法
就数据库存储而言,您的应用程序应根据您向用户和流提供的接口来指定结构.
如果您有用户上传照片并且他们无法选择URI,并且您在流中没有任何层次结构,那么我建议您在主照片表中仅存储ID和stream_id.
如果您有用户上传照片并且他们无法选择URI,并且您在流中没有任何层次结构,那么我建议您在主照片表中仅存储ID和stream_id.
所以至少你可能会有类似的东西
create table photos(id integer primary key,stream_id integer references streams(id) not null);
但您可能还需要与存储无关的描述和其他信息.
流表将具有关于流的所有通用信息,但是具有依赖于流的类型的类的polymorphic association.因此,您可以根据使用的实际流来使用该关联来获取S3Stream或DropBoxStream的实例.
该实例(也是ActiveRecord资源)可以存储访问密钥,以及诸如dropBox之类的东西,文件夹的路径等.此外,该实例可以提供在给定Photo对象的情况下构造URI的方法.
如果特定技术需要缓存签名的URI,那么说S3Stream对象可以引用URI签名的S3SignedUrl模型.
如果事实证明DropBox和S3之间的签名URL代码相似,那么您可能只有一个SignedUrl模型.
当您设计ios和Android客户端时,关键是他们无权访问流所有者的访问令牌.相反,您需要在服务器应用程序内进行所有签名.您不希望设备受损导致暴露访问令牌,从而产生计费问题以及隐私泄露.希望这可以帮助.