Support JWT auth

[ChaoticTempest]

Some partners require utilizing JWT with their applications, so being able to supply it within jsonrpc-client would be great.

This is the expected post call via curl:

curl -vvvv --location --request POST 'https://near-mainnet.dev.api.pagoda.co/rpc/v1/' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer eyJhbGciOiJSUNiJ9.eyJzdWIiOiIxY3ODkwIZSI6ImFkbWluIiwiaXNzIjoiYWRtaW4taXNzdWVyIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.TZXtM_-6jBInZTXK53Mei3eSXR15FXAFilV_CjnW7VxvaMsR-G587d0UUNAggVIH-M5T6UuiPBtj2uQnaila__OZcnmXis4qjlxb1CGir1V1xwaOBSfLZSsczqObhw4wf_84ShfZib3rO2b8hUOozA2tgTjKG4VB8ZWbEtC56CELpSHULKf8rvnNtYVibrfGAiT5B5HaIky_c-odc3HmcTkT8jCV1dqncJgUYidLe2G6beb4WfU-3H0FmNhAiUGJSmhCsocP2Dt7xIITFdBX4RJMpXEy' \
  --data-raw '{"jsonrpc": "2.0", "id":"dontcare","method":"status","params":[] }'

but would be nice to have an interface around it like ApiKey

[ChaoticTempest]

@miraclx does this sound simple enough to add?

[miraclx]

It's already possible to do this externally. Either by implementing HeaderEntry (see this example in Prevalidated). .. or by calling

client.header(
    ("Authorization", "Bearer eyJhbGciOiJSUNiJ9...")
)?;

But yeah, I see certainly see value in exporting a consistent interface that helps with this.

Perhaps something on the order of:

client.header(
    ApiKey::new("83e534d5-adf8-4ff3-..."), // x-api-key: 83e534d5-adf8-4ff3-...
);
client.header(
    Authorization::bearer("eyJhbGciOiJSUNiJ9..."), // Authorization: Bearer eyJhbGciOiJSUNiJ9...
);

Unsure if we should support more than the bearer scheme here, or perhaps we can leave it generic for the users to specify both the scheme and value. Even reqwest only provides helpers for the bearer and basic schemes.

But as a rule of thumb, it's always easier to introduce what's missing than deprecating / straight-up removing features.

[ChaoticTempest]

But as a rule of thumb, it's always easier to introduce what's missing than deprecating / straight-up removing features.

yeah I can understand that, but don't think bearer is something going away in the future, since it's pretty standard. I do think that header(("Authorization", "Bearer eyJhbGciOiJSUNiJ9...")) isn't too intuitive especially since you have to put a space between Bearer and the token. So your snippet with Authorization::bearer looks more clean to deal with this case, but I'll leave this up to you whether you want to add, since the basic functionality is already there

[miraclx]

yeah I can understand that, but don't think bearer is something going away in the future, since it's pretty standard.

yeah, bearer is fine. I was contemplating whether to add the rest of the valid schemes. But for now, I'll settle on starting with bearer and if the need arises for the rest, we can add them incrementally, rather than adding them now and receiving little to no usage. But at least for now, I think bearer holds the greatest value.

[ChaoticTempest]

gotcha, yeah let's just have bearer and add further when there's a need