undefined | Better HN

0 pointstheandrewbailey6y ago0 comments

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).

0 comments

floatingatoll6y ago

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_6y ago

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.

floatingatoll6y ago

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.

j / k navigate · click thread line to collapse

0 comments

floatingatoll6y ago

akerl_6y ago

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

floatingatoll6y ago

j / k navigate · click thread line to collapse