[cosmwasm-stargate] Allow for optional Authorization details when connecting

I saw this comment about Figment’s API keys and thought it would be good to create an issue. https://github.com/cosmos/awesome/issues/17#issuecomment-1019447433

I’m not super familiar with the Cosmos tooling, but I have been successfully talking to a testnet RPC by basically doing:

const client = await CosmWasmClient.connect(RPC_ENDPOINT)
let balance = await client.queryContractSmart('junoAbc123…', {
    balance: { address: encodedAccount },
  })
console.log(`Balance: ${balance.balance}`);

It looks like in the cosmwasm-stargate package, the connect function only takes an endpoint and no more details for authorization.

https://github.com/cosmos/cosmjs/blob/40a1121b8ee358a5fd2a875dcc56714b77ac8e29/packages/cosmwasm-stargate/src/cosmwasmclient.ts#L93-L96

When you look at Figment’s system it’ll give you an API key such that you can access using an Authorization header, like:

curl https://cosmoshub-4--rpc--full.datahub.figment.io/status -H Authorization: abc123…

Might be a consideration to have this connect call take an object instead, so it might have less problems with backwards compatibility later.

For instance, it could be:

 public static async connect({ endpoint: string, authorization: string}): …

Or maybe there’s a way to use the abstraction in cosmjs and add this type of authorization, but I wasn’t able to find it.

[webmaster128]

Good point. I wan’t aware such headers were used in the Cosmos space.

This is the same problem in every CosmJS package that connects to a node. If we start working on this, I would not add autorization support but HTTP headers in general. Next user will need cookies or something custom here.

An alternative solution would be https://github.com/cosmos/cosmjs/pull/981 where you create a wrapper RPC object that injects the headers. However, I’m not exactly sure if we should support #981 right now.

[webmaster128]

I think this is pretty clear. It’s just a matter of API design. Do we want the functionality and do we want it this way. While it might look simple for this use case, there are other things to consider, like: what are the implications for websocket users? Will websockets even be relevant in the future? What about grpc enpoints to connect to? What’s a good name for interface if we make it public?

The change would be relatively easily to implement it it was just the Tendermint 0.34 client. But it has to propagate though all the stack to be usable in the higher level clients.