© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
> Relatedly, do we support/acknowledge the Expires query parameter today?
Yes, presigned urls (which require the Expires query param) are supported. Swift3 doesn't currently have a limit on how far into the future the Expires timestamp can be (!), but according to [1] one week is the limit in AWS (at least for v4 signatures). We might be able to drop to 48 or even 24 hours without users complaining too much, but shorter than that will severely restrict the utility of presigned urls. On the other hand, though, 24 hours is an awfully long time to be able to impersonate a user.
> requires new configuration on the part of deployers
On the plus side, all of the new configuration (assuming a service token approach) should already be present for the authtoken middleware; it should just be a matter of copying it for s3_token.
> 3. deployer will also need to worry about time skew. Though it may not be a big deal as all the controllers are expected to be running NTP.
I wouldn't worry about that, for precisely the reason you've outlined.
> not to directly expose the Keystone S3 and EC2 APIs to the public
This is core to the problem. There's no reason that an end-user should ever hit the S3 extension themselves. However, I'm not clear on how deployers could limit that access given v3's move toward a single unified pipeline.
Stepping back for a moment, why does the S3 extension issue a token at all? Doesn't this create a separate token for every client request? Could we drop the token from the S3 extension's response, then have s3_token create its own token, cache it with a drastically shorter cache time (measured in seconds rather than minutes), and continue stuffing it into the WSGI environment for auth_token to consume?
[1] http://