-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Returned status: Forbidden #56
Comments
happens to me aswell, tried it for the first time today because of the "Collection #1" list |
I fired up fiddler to see what the response was and it appears that the plugin has breached the acceptable use policy (html returned below) but it isn't apparent if this is a rate limiting issue or if it is too many requests from single IP
|
Having checked the Pwnd Password docs here I don't believe its anything to do with rate limiting as that should return a 429 but instead I'm seeing a 403 |
The plugin should always be rate limited in its requests to the API, so I wonder if it had accidentally triggered the "multiple IP addresses" check because obviously there will be a lot of requests from different IPs. |
Could this be due to the sheer number of checks from a single IP? When I tried running it, it went through ~half my username list, then started getting an error for every entry, even if I waited for several seconds between attempts. Also - it's impossible to gracefully cancel plugin execution is this case, had to terminate KeePass process to abort. |
One more thing I'd noticed: if progress indicator is to be believed, it definitely checks faster then once every 1.6s (I'd say, at least couple entries per second). |
I was accessing the API manually earlier and got the same forbidden page. I think there is something wrong with hibp's API for now. Accessing other endpoints (pastes. pwned-pws) are accessible though. I also tweeted haveibeenpwnd about it to make sure. |
Although the problem might be API related, there should be the possiblity to cancel the process. These error messages pop up over and over again ... |
Just ran site/service and username checks and had no issues myself. Either it's a temporary hiccup that resolved or my username count is severely low compared to yours. |
Works fine for me |
Yep, works again since today. |
I can reproduce the error when checking site or password by selecting the option "Check all supported breaches" without this option checked it runs successfully. When trying to run the check via username even without the "Check all supported breaches" I'm getting the forbidden error but it appears that it is trying to get breaches so guessing its related. |
Same here Even more anoying is that you have to dismiss the dialog for every single entry in your keepass file. That kept me busy for 15 minutes. :( |
I'm stuck on this as well, under Ubuntu (see #58 ) ... |
Same Error only with usernames
I'm not sure where to get the Error code 403 but this is about: no user agent: |
That shouldn't be the issue, as the plugin always sets the user agent appropriately
|
As mentioned on the Api-Website And you have already added Delay but only for usernameChecks and not for the other checks. Line 102 in d78ade5
|
Unless Troy has changed something and not updated the docs, I don't think this is the issue. The API page specifically says
Additionally the site/service check only does 1 call to retrieve the entire list of breaches, and then compares entries locally. |
I have installed latest release today and can confirm that all of the searches are working correctly (regardless of if "Check all breaches" is checked or unchecked 👍 |
Is this still an issue for people? |
I just check with Keepass 2.41 and the plugin 1.3.1, but the issue is not resolved ("Returned status: Forbidden") |
Right, I've fired off an email to Troy about this. Hopefully he can offer some insight into why this is happening. |
I just got ran into this last night, here's what shows up when I manually attempt to query the API (example URL)
|
So I've done a bit more investigation in my case, and the plugin is still popping up an error message saying All I have to do to reproduce it is check for breaches based on username and uncheck all boxes. The error page from my previous comment seems to have been caused by the haveibeenpwned API rejecting requests from web browser user agents (as is documented in the API docs). The above API URL does work over curl though (with the user agent |
If you can reliably reproduce the error from within keepass, can you try capturing the error response by using fiddler (https://www.telerik.com/fiddler) or a similar tool? Troy needs to see the exact response returned by cloudflare in order to debug this. You're right that using a browser is not a valid test, as cloudflare rejects this based on the user agent, but it is interesting that the request fails from within keepass, but works via curl. I haven't been able to reproduce the error on any of my systems (using at least 3 different IP addresses from different locations), either using the plugin, or with postman etc. |
Downloaded and installed and "learned" Fiddler.
First answer:
Reconnect to provider some times to get new Ip adress -> Same answer Start VPN it works |
Thanks, I've forwarded the details on to Troy. It does look like cloudflare using an over enthusiastic IP range blocker that is causing this. |
So for me, this turned out to be an IP blocking issue. I had previously been doing some testing with IE over a VPN and forgot to reset its proxy settings, and it looks like Keepass picks up the IE proxy settings, so all of the plugin's traffic was going over the VPN whereas curl, etc. did not. Trying the same curl commands on the other end of the VPN failed, and after clearing the IE proxy settings, the keepass plugin started working again. |
Same problem. Fresh install of keepass and this plugin. No proxy involved. No other users on this IP even looking at haveibeenpwned. |
I got the same error here when letting the plugin search for usernames and ticking the box |
OK everyone, I've chatted to Troy about this, and he says the only way for him to get to the bottom of this is for him to get copies of the error response returned by cloudflare, including the IP address (if this is missing, it's useless to him). Since this isn't easily accessible when using KeePass (unless you're willing to run Fiddler, or another inspecting proxy), I'd like to have a show of hands of who would be willing to test a version of keepass that specifically saves these cloudflare error messages so we can send them to Troy. Please 👍 this message if you're happy to take part so I know it's worth my time creating a debug build. |
You mean this? Do I share the result here or what? 😅 I've KeePass and Plugin updated, and I always have the same problem. :c! |
@SoyRA No, that link will always fail because of the browser user-agent. We need the response from a valid request from KeePass. |
Thanks for your work. Happy to help out if needed. |
This is hitting me as well, and I'd be willing to run a beta plugin for testing purposes if it'll help solve this once and for all. |
I've attached a "rough-and-ready" debug version of the plugin which will store the cloudflare error responses returned from HIBP.com This will dump a txt file into Debug download: HaveIBeenPwned.zip |
I sent an email with debug file. |
Here's two of my error response. Received when trying to run username check. Both site and password checks have worked. |
I've ran the beta plugin and also sent you an email with a number of debug files. As stated previously I can only get errors by searching on username. |
I believe this should be fixed now that HIPB API v3 has been released, however I'd be interested in knowing if people are still seeing this issue with >= v1.3.4 of the plugin. |
Tested with 1.3.4 |
Let's see, everything works. The only "problem" is trying to use (...) based on username because it asks me for the API Key...But taking that out, everything's fine. :P |
I received this error when running the plugin, after clicking OK in the settings prompt for the plugin. I haven't previously used the plugin, so I do not know if this is a temporary issue, but https://haveibeenpwned.com/ is working. I believe it could be an HTTP 403.
Let me know if I can provide more relevant information.
The text was updated successfully, but these errors were encountered: