Request blocked or forbidden about hibp HOT 8 CLOSED

If anyone has any corrections, additional information, or suggestions, please comment here. I've been communicating with Troy Hunt of haveibeenpwned.com in an attempt to determine a way forward, but I've gotten nowhere.

from hibp.

Any more updates on this?

I think we're just going to have to move away from the library all together as it seems absolutely fine if I use Fetch/Axios with a custom UA.

from hibp.

Can you provide more details around exactly what you're doing that works? Are you running in Node.js or a browser?

I can add an option to allow setting your own UA, but that is only temporarily side-stepping the problem (you may get blocked again, requiring you to change the UA, which is actually against Troy's acceptable use policy) and would only currently work in Node.js environments (as stated multiple times).

from hibp.

I wish I could provide more information other than the fact all I'm doing is setting a custom UA. The UA is specific to our product and Troy is aware as we've been in contact with him before regarding this issue and before we integrated it into our platform. If we set the UA, it works, if we don't or use the default in your library, it doesn't work.

I think the option to add your own UA is a useful feature as it's explained on his website that the UA should describe the service using it.

I wish I could on the browser side of things but I have no ideas other than discussing that with Troy?

from hibp.

OK, so you're in Node.js. Which version of hibp are you using? Have you tried that same version from a different network/location? I suspect the blocks are a combination of UA and IP as the same version of hibp (i.e. same UA) works for some people but not everyone (the difference being which Cloudflare region they hit).

As for the browser, what do we do? As I see it, there are only 2 options: Troy relaxes the new rules to allow browser UA's again, or we drop browser support from the library - which would be a bummer. 🙁

from hibp.

I just emailed Troy one more time in hopes of getting an answer with regards to the browser. We need to establish if browser UAs are intentionally and permanently blocked for the breachedaccount endpoint (meaning we drop browser support from hibp) or if he just has something misconfigured/overly strict. 🤞

from hibp.

Troy responded and confirmed browser UAs are intentionally blocked. This policy seems to be currently applied the breachedaccount endpoint only. He has not clarified (yet) if the other endpoints will start blocking browser UAs or not.

For the time being, I suppose I will update hibp to throw an error if you attempt to call the breachedAccount function from within a browser and document that the upstream API has denied that particular action. If it turns out all the endpoints adopt this same policy, I will probably remove browser support from hibp entirely.

@kierxn If you can tell me which version of hibp you're using that gets blocked and confirm that you've tried that same version from multiple networks/locations and still got blocked, that would be quite helpful.

I'm tempted to just expose the Axios instance itself (or similar), so you can customize it however you wish (custom UA, proxy requests through your own server somewhere to get around the browser block, etc.) but that really locks us into that particular implementation detail. Meh. Edit: I'll just expose UA and baseUrl (for proxying) configuration options and leave it at that.

from hibp.

I've exposed some additional options to help alleviate these problems (released in [email protected]). Closing the issue for now as there is probably nothing else we can do at the library level at this time. Feel free to comment if any new information becomes available.

from hibp.