support swift tempURLs

[anshrupani]

swift tempURLs are not compatible with the S3 API calls in s3cli.

Therefore, we implement a signed URL provider which determines which provider to delegate the signed URL call to, the s3 provider or the swift provider.

We also implement the swift client to extend the signed URL functionality for swift/openstack compatibility.

[aramprice]

I'm curious why there is a conditional in client.NewSignURLProvider() which can return different clients, rather than having client.S3Blobstore.Sign() use the contents of config.S3Cli (which it already has access to) to conditionally choose the signing method?

What I have in mind would look something like:

func (client *S3Blobstore) Sign(objectID string, action string, expiration time.Duration) (string, error) {
	if client.s3cliConfig.SwiftAuthAccount != "" {
		return client.swiftSign(objectID, action, expiration)
	}

	return client.s3Sign(objectID, action, expiration)
}

func (client *S3Blobstore) s3Sign(objectID string, action string, expiration time.Duration) (string, error) {
	// implementation
}

func (client *S3Blobstore) swiftSign(objectID string, action string, expiration time.Duration) (string, error) {
	// implementation
}

Something like this would add swift signing behavior without adding a different signing-only client, and hides the details behind client.S3Blobstore.Sign().

[mvach]

I would not mix up the S3 client code with Swift specific implementations because I wouldn't expect Swift Code in that client.
So I do prefer making it obvious like the current implementation does. But that's more a question of taste ...

[aramprice]

I guess I was confused about the origin of Swift in this case. I thought it was an extension of S3 in some way.

I agree that the Swift code doesn't belong on the client.S3Blobstore struct.

I do think that client.New() should return a generic client which has a an interface that matches that of client.S3Blobstore and has a Sign() implementation that is similar in spirit to my example above but instead calls out to whichever internal entity supports AWS S3, or Swift when Sign() is called.

func (c *GenericS3Blobstore) Sign(objectID string, action string, expiration time.Duration) (string, error) {
	if client.s3cliConfig.SwiftAuthAccount != "" {
		return c.someEntityWhichSupportsSwift.Sign(objectID, action, expiration)
	}

	return c.someEntityWhichSupportsAwsS3.Sign(objectID, action, expiration)
}

The GenericS3Blobstore should export an interface which matches:

type Blobstore interface {
	Put(src io.ReadSeeker, dest string) error
	Delete(dest string) error
	Exists(dest string) (bool, error)
	Sign(objectID string, action string, expiration time.Duration) (string, error)
}

The code in main shouldn't know, or need to know that Sign() can have multiple implementations depending on what config was passed. The result of calling client.New() should be an entity which satisfies the interface above and performs operations like Sign() based on the config is passed to New()

[mvach]

This method should be private

[mvach]

I would not mix up the S3 client code with Swift specific implementations because I wouldn't expect Swift Code in that client.
So I do prefer making it obvious like the current implementation does. But that's more a question of taste ...

[lnguyen]

LGTM