Allow generate signed url for upload objects

[Xuanwo]

We provide an API Reach for generating an URL for an object for the user to get.

Maybe we can provide like Reach but for uploading an object.

[Xuanwo]

• Reach -> generating url for Read
• Xxxxx -> generating url for Write
• ....

Maybe we can provide a higher-level abstraction for those operations?

Something like Generate(op, path string) (verb, url string) -> Generate("read", "abc.png") -> ("GET", "https://xxxx.com/abc.png")

[Xuanwo]

query sign is rarely used except for GetObject and PutObject, maybe we don't need to support general query sign support.

[Xuanwo]

How about add API like: (maybe Signer / Sign)

type Accessor interface {
    Access(op, path string, pairs...) (req *http.Request, err error)
}

Or

type Accessor interface {
    AccessRead(path string, pairs...) (req *http.Request, err error)
    AccessWrite(path string, pairs...) (req *http.Request, err error)
}

[JinnyYi]

We can implement it as most object support SignedURL.

For Accessor, I have two other doubts：

• What's the difference between Reach() and AccessRead()? Both of them are used for reach an object, maybe AccessRead() is not needed?
• If the service only support AccessRead(), like kodo, does it mean we can't implement Accessor for it?

From simplicity, maybe we can just support PutObjectWithURL. Conversely, maybe we can implement Generate(op, path string) (verb, url string) -> Generate("read", "abc.png") -> ("GET", "https://xxxx.com/abc.png") mentioned above, and services should maintain a list of supported authorized access operations and check whether op is supported.

[Xuanwo]

Our users have a need to support the generation of a signed URL that allows their end-users to upload/download the corresponding data directly.

Operations that they need include: (take S3 as an example)

• PutObject
• GetObject
• CreateMultipart
• WriteMultipart
• CompleteMultipart

[Xuanwo]

Hi, I camp up a new idea that, we can define a new interface like:

type HttpSinger interface {
    QuerySignHttp(req *http.Request, ps ...types.Pair) (signedReq *http.Request, url string, err error)
//    HeaderSignHttp(req *http.Request, ps ...types.Pair) (signedReq *http.Request, auth string, err error)
}

For now, HeaderSignHttp is not required, we can add them later.

This interface can deprecated Reach API.

[JinnyYi]

QuerySignHttp(req *http.Request, ps ...types.Pair) (signedReq *http.Request, url string, err error) is indeed more universality. We can generate request's signed URL in QuerySignHttp.

As external methods are provided for obtaining signed URL for most services, maybe the parameter req *http.Request complicates matters：

• Users need to pass in the req.URL correctly.
• We need to parse req.URL to get the wanted request resource(operation, path...).

How about one of the following methods：

• QuerySignHttp(op, path string, ps ...types.Pair) (signedReq *http.Request, err error)
• QuerySignHttp(req *Request, ps ...types.Pair) error

  type Request struct {
      Name        string  // "GetObject"
      HTTPPath    string  // "{Key+}"
      HTTPRequest  *http.Request
      ...
  }
  

[Xuanwo]

req, err := store.QuerySignHttp(types.OpRead, "abc")

req, err := store.QuerySignHttp(types.OpWrite, "abc", pairs.WithContentType("application/json"))

req, err := store.QuerySignHttp(types.OpWriteMultipart, "abc", pairs.WithMultipartId("qqqq"))

Looks nice.

[JinnyYi]

req, err := store.QuerySignHttp(types.OpRead, "abc")

req, err := store.QuerySignHttp(types.OpWrite, "abc", pairs.WithContentType("application/json"))

req, err := store.QuerySignHttp(types.OpWriteMultipart, "abc", pairs.WithMultipartId("qqqq"))

I will continue the GSP based on this.