[floatingatoll]

See also elsethread about "not a token" — but, also:

> There's a couple of these and they're largely due to me trying to make sure I get this feature out as early as possible and continue to run things on a shoestring cost wise

Using the Authorization header can cause significant problems with both clients and servers, and also might unintentionally permit browsers to directly query the server if they can be convinced to provide a bearer token.

Using a custom HTTP header sidesteps both client and server issues altogether and closes the door on browsers direct-querying the API, which could be considered a positive by the site operator.

[theandrewbailey]

I'm not sure how browsers using the API would be a concern. Someone paid for the key, so it should be up to them to use it how they please (within rate limits).

[floatingatoll]

Allowing browsers to query directly would break the terms of engagement specified by the site operator, who specified that a proxy shall be used to concentrate end-user requests for a given paid key. That’s their right as service operator. I can construct plausible scenarios why this is a sensible choice, but the underlying point is that they clearly regardless made that choice after thinking it through.

[akerl_]

That’s not a requirement specified anywhere. The “Protecting the API Key“ section talks about using a proxy specifically in the context of client-side applications (think of things like 1Password that integrate w/ HIBP), where embedding the API key into the app is obviously undesirable. In those cases, using a proxy allows managing the request volume and injecting the API key.

That same section of the document describes other scenarios, like a hosted service or a CLI tool, that do not involve a proxy service.

[floatingatoll]

I look forward to clarification someday from the operator - but that custom header will still block non-extension browser-side calls in v3, and I bet the ACAO header isn’t present to allow it either.