Question

我正在开发一个用户加入“流”的项目。在流设置期间，创建流的人（流创建者）可以选择：

将成员添加到流中的所有照片上传到我们的托管解决方案（S3）
将成员添加到流中的所有照片上传到流创建者自己的Dropbox身份验证文件夹

将来我想添加更多存储提供商（例如Drive，Onesky等）

关于如何解决这个问题，我有几个不同的问题。

照片数据库中的结构应该是什么？我目前只有photo_url，但从数据的角度来看，使用预先签名的网址以及上传照片的方式不同（s3，dropbox等）不容易管理。
如何存储每个存储提供商的访问令牌？请记住，只会存储流创建者的access_token，并且流上的所有人都会在上传照片时共享该令牌
我将在未来添加iOS和Web客户端，直接上传到存储提供商并绕过服务器以避免服务器负载过重

Answer 1

就数据库存储而言，您的应用程序应根据您向用户和流提供的接口来规定结构。如果您有用户上传照片并且他们无法选择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客户端时，关键是他们无法访问流所有者的访问令牌。相反，您需要在服务器应用程序内进行所有签名。您不希望设备受损导致暴露访问令牌，从而产生计费问题以及隐私泄露。希望这会有所帮助。

Answer 2

我们设置了许多具有不同类型文件存储的rails应用程序。

是的，将来只是一个网址无法管理。为了节省大量时间，您可以使用carrierwave或paperclip等宝石。它们处理所有缩略图生成和文件验证。一种方法是，您可以将文件从客户端直接上传到S3或Dropbox到tmp文件夹，然后告诉您的Rails应用程序“嘿，这是新上传文件的URL”，回形针和载波将负责处理缩略图生成和存储。（Example for paperclip）
不确切知道你的流是如何工作的，所以我不能给出一个好的答案--.-
使用我在1.中提到的设置，您应该将您的不同客户端直接上传到S3或Dropbox等。上传后，客户端告诉Rails后端它应该从该URL导入文件。（在回形针或载波完成处理之前，您可以使用文件中的tmp url直接在流中显示内容）

Rails：允许用户将图像上传到Dropbox链接文件夹或Amazon S3上的“我们的”存储的最佳方式

2 个答案: