support for basic auth

[MichaelMure]

When exposing a node's API over the internet, it's a common thing to have it behind a proxy and to protect it with authentication, the simplest one being HTTP BasicAuth.

While js-ipfs-http-client doesn't explicitly support authentication, it's relatively easy to use the custom header features to pass a Basic Auth header, such as: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

It's much trickier to do that with go-ipfs-api. While it's possible to construct the shell with NewShellWithClient() and to pass a custom http.Client, go's http.Client only support setting cookies.

The only way I found was to implement a custom http.Client with an overridden http.RoundTripper that will intercept each request to set the proper Basic Auth. But obviously, that's rather hacky and will break if a custom RoundTripper is required for an actual good reason.

Would you be willing to support those use-case natively in go-ipfs-api ?

This could be done two different ways:

• as js-ipfs-http-client does, support custom headers
• explicitly support Basic Auth

[Stebalien]

I believe you can set the server to https://user:password@mydomain.com. However, I'd be open to SetCookie and SetCredentials methods.

[maurocordioli]

I have an issue similar the one depicted by @MichaelMure as I have to connect to a ipfs api/http with a JWT authentication token so I cannot use the proposed "https://user:password@mydomain.com" scheme. a "SetAuthorization" method that sets the Authorization header could be beneficial to multiple use cases (Bearer JWT ,basic. ... )

[Stebalien]

FYI, the go-ipfs-http-api now supports setting arbitrary headers (https://godoc.org/github.com/ipfs/go-ipfs-http-api#HttpApi). We still consider the interfaces in that library to be unstable but, if you're willing to deal with that, I recommend you try using it instead of this library.

[autonome]

Reviewed in triage, still needed but low priority. Would take a patch.

[SteMak]

Still neaded)

[D3vl0per]

Bump!