mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2025-12-10 17:23:04 +03:00
Data breach option from web vault gives 401 #1773
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @manofthepeace on GitHub.
Subject of the issue
Using webvault 2.13.1, when using data breach report, I always get a 401 unauthorized error. HIBP_API_KEY is set properly, and works for exposed passwords report. I cannot say if it worked with older version or older vault has I just got a hibp key.
I did try to restart bitwarden_rs and also logout and back in in the web vault but same thing happens. Tested with firefox and chrome.
Your environment
Steps to reproduce
1-go to web-vault 2.13.1, #/tools/breach-report
2-enter a email address in the box, or username
3-Click check breaches
Expected behaviour
Should get the report instead of the error.
Actual behaviour
Getting a 401 in the logs and the UI is showing a red error popup "An unexpected error has occurred"
Relevant logs
@manofthepeace commented on GitHub:
Ok false alert, sorry for the noise. There was an extra char in the key I did input in the env file. What mislead me was the fact that the check from within the mobile app, and also the exposed password report from web-vault worked.
Also curl was working fine with my key, but the extra char was not there.
I did look at the code, I saw that the key seemed to be added to the header properly, and if the key was missing I would get something like this.
{ "statusCode": 401, "message": "Access denied due to missing hibp-api-key." }Still unsure how other functionalities were working, but maybe its the only one that actually needs the api key.
Thank you.
@BlackDex commented on GitHub:
Are you sure the api key is correct? Please double check in the /admin interface.
Only the email breach report needs the api key. The exposed passwords are free to use.
I don't have a api key so i can't check. But the code looks oke, just as the API documentation tells it to be.