This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode

带有基于前缀作用域的临时 URL

临时 URL 中间件应该允许使用基于前缀的签名，这授予对所有具有此特定前缀的对象访问权限。 这允许使用一个签名访问整个容器或伪文件夹，而不是为每个对象使用新的签名。

问题描述

目前，如果想与外部人员共享容器/伪文件夹内的大量对象，则必须为每个对象创建临时 URL。 此外，在生成签名后放置在容器/伪文件夹内的对象无法使用相同的签名访问。 基于前缀的签名将允许重用相同的签名来处理共享相同前缀的大量对象。

用例

1. 我们有一个包含 1000000 个对象的伪文件夹。 我们想与外部合作伙伴共享此伪文件夹。 与生成 1000000 个不同的签名相比，我们只需要生成一个签名。
2. 我们有一个基于 swift 的 Web 应用程序，例如 swiftbrowser (https://github.com/cschwede/django-swiftbrowser)，它充当文件浏览器。 我们希望支持与外部人员共享临时伪文件夹。 我们事先不知道将存在于伪文件夹中哪些对象以及有多少对象。 使用基于前缀的签名，我们可以以这样一种方式开发 Web 应用程序，即用户可以为单个伪文件夹生成一个临时 URL，外部人员可以使用该 URL 访问所有将存在于其中的对象（此用例还需要一个临时容器列表，以显示存在于伪文件夹中的对象，以及对 formpost 中间件的修改，请参阅规范 https://review.openstack.org/#/c/225059/）。

提议的变更

临时 URL 中间件应该被更改。 代码更改不应太大。 如果客户端希望使用基于前缀的签名，他可以附加一个 URL 参数“temp_url_prefix”以及所需的 前缀（空前缀将指定整个容器），并且中间件将仅使用容器路径 + 前缀来计算签名。 此外，中间件将检查对象路径是否确实包含此前缀。

让我们举两个例子。 在第一个例子中，我们希望允许用户在容器 c 中上传一堆对象。 他首先创建一个 tempurl，例如使用 swift 命令行工具（修改后的版本，支持容器级别作用域的 tempurls）

$swift tempurl --container-level PUT 86400 /v1/AUTH_account/c/ KEY
/v1/AUTH_account/c/?temp_url_sig=9dd9e9c318a29c6212b01343a2d9f9a4c9deef2d&temp_url_expires=1439280760&temp_url_prefix=

然后用户使用每次相同的容器级别签名上传一堆文件

$curl -XPUT --data-binary @file1 https://example.host/v1/AUTH_account/c/o1?temp_url_sig=9dd9e9c318a29c6212b01343a2d9f9a4c9deef2d&temp_url_expires=1439280760&temp_url_prefix=
$curl -XPUT --data-binary @file2 https://example.host/v1/AUTH_account/c/o2?temp_url_sig=9dd9e9c318a29c6212b01343a2d9f9a4c9deef2d&temp_url_expires=1439280760&temp_url_prefix=
$curl -XPUT --data-binary @file3 https://example.host/v1/AUTH_account/c/p/o3?temp_url_sig=9dd9e9c318a29c6212b01343a2d9f9a4c9deef2d&temp_url_expires=1439280760&temp_url_prefix=

在下一个例子中，我们希望允许外部用户下载整个伪文件夹 p

$swift tempurl --container-level GET 86400 /v1/AUTH_account/c/p KEY

/v1/AUTH_account/c/p?temp_url_sig=4e755839d19762e06c12d807eccf46ff3224cb3f&temp_url_expires=1439281346&temp_url_prefix=p

$curl https://example.host/v1/AUTH_account/c/p/o1?temp_url_sig=4e755839d19762e06c12d807eccf46ff3224cb3f&temp_url_expires=1439281346&temp_url_prefix=p
$curl https://example.host/v1/AUTH_account/c/p/o2?temp_url_sig=4e755839d19762e06c12d807eccf46ff3224cb3f&temp_url_expires=1439281346&temp_url_prefix=p
$curl https://example.host/v1/AUTH_account/c/p/p2/o3?temp_url_sig=4e755839d19762e06c12d807eccf46ff3224cb3f&temp_url_expires=1439281346&temp_url_prefix=p

由于缺少/错误的前缀，以下请求将被拒绝

$curl https://example.host/v1/AUTH_account/c/o4?temp_url_sig=4e755839d19762e06c12d807eccf46ff3224cb3f&temp_url_expires=1439281346&temp_url_prefix=p
$curl https://example.host/v1/AUTH_account/c/p3/o5?temp_url_sig=4e755839d19762e06c12d807eccf46ff3224cb3f&temp_url_expires=1439281346&temp_url_prefix=p

备选方案

可以引入一个新的中间件。 但这似乎只会导致大量的代码复制，因为与原始中间件相比，更改非常小。

实现

负责人

主要负责人

bartz

工作项

添加对 tempurl 和各自测试模块的修改。

仓库

无

服务器

无

DNS 条目

无

文档

修改 tempurl 中间件的文档。

安全性

签名的计算使用 hmac 模块 (https://docs.pythonlang.cn/2/library/hmac.html) 结合 sha1 哈希函数。 基于前缀的签名与当前基于对象路径的签名之间的区别在于，路径被缩小到前缀。 计算的其余部分保持不变。 较短的路径会产生较短的消息作为 hmac 计算的输入，这不应降低加密强度。 因此，我没有看到引入基于前缀的签名存在安全相关的问题。

测试

应该将测试添加到现有的测试模块。

依赖项

无