diff --git a/specs/in_progress/prefix_based_tempurl.rst b/specs/in_progress/prefix_based_tempurl.rst new file mode 100644 index 0000000..aa715a6 --- /dev/null +++ b/specs/in_progress/prefix_based_tempurl.rst @@ -0,0 +1,146 @@ +:: + + This work is licensed under a Creative Commons Attribution 3.0 + Unported License. + http://creativecommons.org/licenses/by/3.0/legalcode + +.. + +===================================== +tempurls with a prefix-based scope +===================================== + +The tempurl middleware should be allowed to use a prefix-based signature, which grants access for +all objects with this specific prefix. This allows access to a whole container or pseudofolder +with one signature, instead of using a new signature for each object. + + +Problem Description +=================== + +At the moment, if one wants to share a large amount of objects inside a container/pseudofolder +with external people, one has to create temporary urls for each object. Additionally, objects which +are placed inside the container/pseudofolder after the generation of the signature cannot +be accessed with the same signature. +Prefix-based signatures would allow to reuse the same signature for a large amount of objects +which share the same prefix. + +Use cases: + +1. We have one pseudofolder with 1000000 objects. We want to share this pseudofolder with external + partners. Instead of generating 1000000 different signatures, we only need to generate one + signature. +2. We have an webbased-application on top of swift like the swiftbrowser + (https://github.com/cschwede/django-swiftbrowser), which acts as a filebrowser. We want to + support the sharing of temporary pseudofolders with external people. We do not know in advance + which and how many objects will live inside the pseudofolder. + With prefix-based signatures, we could develop the webapplication in a way so that the user + could generate a temporary url for one pseudofolder, which could be used by external people + for accessing all objects which will live inside it + (this use-case additionaly needs a temporary container listing, to display which objects live + inside the pseudofolder and a modification of the formpost middleware, please see spec + https://review.openstack.org/#/c/225059/). + + +Proposed Change +=============== + +The temporary url middleware should be changed. The code change should not be too big. +If the client desires to use a prefix-based signature, he can append an URL parameter +"temp_url_prefix" with the desired prefix (an empty prefix would specify the whole container), +and the middleware would only use the container path + prefix for calculating the signature. +Furthermore, the middleware would check if the object path really contains this prefix. + +Lets have two examples. In the first example, we want to allow a user to upload a bunch of objects +in a container c. +He first creates a tempurl, for example using the swift command line tool +(modified version which supports tempurls on container-level scope): +:: + + $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= + +The user then uploads a bunch of files using each time the same container-level signature: +:: + + $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= + +In the next example, we want to allow an external user to download a whole pseudofolder 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 + +Following requests would be denied, because of missing/wrong prefix: +:: + + $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 + + +Alternatives +------------ + +A new middleware could be introduced. But it seems that this would only lead to a lot of +code-copying, as the changes are really small in comparison to the original middleware. + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + bartz + +Work Items +---------- + +Add modifications to tempurl and respective test module. + +Repositories +------------ + +None + +Servers +------- + +None + +DNS Entries +----------- + +None + +Documentation +------------- + +Modify documentation for tempurl middleware. + +Security +-------- +The calculation of the signature uses the hmac module (https://docs.python.org/2/library/hmac.html) +in combination with the sha1 hash function. +The difference of a prefix-based signature to the current object-path-based signature is, that +the path is shrunk to the prefix. The remaining part of the calculation stays the same. +A shorter path induces a shorter message as input to the hmac calculation, which should not reduce +the cryptographic strength. Therefore, I do not see security-related problems with introducing +a prefix-based signature. + +Testing +------- + +Tests should be added to the existing test module. + +Dependencies +============ + +None