On 27 July 2015 at 17:01, Sam Whited <[email protected]> wrote: > As mentioned off list, I have two concerns with the protocl as it stands: > > While the simplicity is laudable, the proposals use is extremely > limited by the fact that headers can not be defined. I would like to > see a methohd for passing down arbitrary headers which should be sent > with the PUT request. This would allow a few different use cases: > > 1) Authenticated requests (eg. generate a 1 time use oauth token, tell > the client to use an `Authentication: Bearer <token>` header) > 2) Easily match signed requests; I did an example implementation where > the server delegated storage to Amazon S3. The server would generate a > pre-signed upload URL with a limited TTL, then the client would make a > PUT to this URL. However, the headers did not match, so I had to > modify the client to add a Content-Type header which was required by > Amazon. Other headers might be required as well, and this would mean > implementaitons which use services like this would only be compatible > with certain clients > 3) It would allow (in the simplest case) for sending down a nonce over > XMPP which the client would send back up, thereby validating that the > client is actually the one doing an upload (and the URL wasn't just > guessed by an attacker).
I'll just quickly note that I don't see any security advantage to a token in a header (if we're always over HTTPS, which I assume we are if we care about this). The attacker guessing an unpredictable URL is no different to an attacker guessing an unpredictable auth token. Regards, Matthew
