mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Creating passkeys fails: Uncaught (in promise) Error: The operation either timed out or was not allowed. #2131
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 @brianjmurrell on GitHub (Jan 16, 2025).
Vaultwarden Support String
Nothing happens when I click on the

button. Developer tools console in the browser doesn't even show anything new.
On reloading that
/admin/diagnosticspage however the console does report:Maybe that is why.
Vaultwarden Build Version
v1.32.7
Deployment method
OS Package (apt, yum/dnf, pacman, apk, nix, ...)
Custom deployment method
No response
Reverse Proxy
Not yet
Host/Server Operating System
Linux
Operating System Version
Fedora 40
Clients
Browser Extension
Client Version
2024.12.4
Steps To Reproduce
Expected Result
Passkey should be saved.
Actual Result
Devtools console reports:
Logs
Screenshots or Videos
No response
Additional Context
Passkeys add fine using the same browser, extension, etc. when using the bitwarden.com vault server.
@brianjmurrell commented on GitHub (Jan 16, 2025):
I am able to create a passkey on Android 15 with BW and Vaultwarden.
Maybe a separate issue but likely related, trying to log in with a passkey (created as above on Android with BW and Vaultwarden) on Chrome with the browser extension results in the BW browser extension saying "No passkeys found for this application" and Vaultwarden logs:
@brianjmurrell commented on GitHub (Jan 16, 2025):
Same kinds of errors (without any devtools console errors however) on passkeys.io:
@BlackDex commented on GitHub (Jan 16, 2025):
The
/admin/diagnosticspage doesn't even look how it should look.It doesn't load the Javascript files probably or something else is breaking your environment, like extensions in the browser which break stuff.
The
/identity/connect/tokenreturns a 400 in case you need to identify with a 2FA/MFA method first, so that seems to be normal.I suspect that your reverse proxy or tunnel provider is causing issues by either not sending the requests to Vaultwarden, or blocking other items. And, also some security extensions could cause issues like
nojsor extensions which clear local storage or prevent cookies or other headers.Also make sure you are not setting any security headers your self in your reverse proxy, except maybe for the HTST one, since that is not something Vaultwarden determines.
@brianjmurrell commented on GitHub (Jan 16, 2025):
No? I did only paste a portion of it. The entire page looks like:
DevTools seems to show it seems to be loading JS files:
Nothing else, anywhere breaks in the very same browser so that doesn't seem very likely.
I have confirmed that this behaviour is reproducible in a brand new/fresh Chrome installation that has no extensions installed at all (except what Chrome installs by default):
I don't have any reverse proxy or tunnel providers (exactly for the reason of not introducing more moving parts while I evaluate). I am in fact using Rocket's HTTPS support. I realize that that is not suggested but it's only temporary while I evaluate Vaultwarden. If I move forward to production with it I will use a reverse proxy.
I don't have any extensions of that sort that I am aware of.
Again, no reverse proxy involved here.
But honestly, this whole issue of the diagnostics Generate Support String is just an aside to the actual issue here is the failure to complete the passkey storage with Vaultwarden, that does not happen with the bitwarden.com vault.
But I did take advantage of that fresh Chrome installation to re-test adding a passkey to Vaultwarden and it did work, so this issue could be closed or could be used to pursue the issue with the
/admin/diagnosticspage's Generate Support String not working if you wish.@BlackDex commented on GitHub (Jan 16, 2025):
The js issues is because you are running a version which doesn't have the version number, which is not intended of course.
But that part of the code i was already making some changes on, so closing this is fine by me.
@brianjmurrell commented on GitHub (Jan 16, 2025):
Just so I am clear on my side, this is a bug in the Vaultwarden version I am running and not an error on my part or on the part of the software building/packaging?
@BlackDex commented on GitHub (Jan 16, 2025):
Depends on how you build it, or where you got the binary from.
If this is without .git information, then it's your building process which is missing the details to extract it.
29f2b433f0/build.rs (L37-L40)@brianjmurrell commented on GitHub (Jan 16, 2025):
It's being built from the release tarball into an RPM. So likely there is no git information for
version_from_git_info()to pull from.Is the implication that the user should set the
$VW_VERSIONenv. variable invaultwarden's environment for such builds?@BlackDex commented on GitHub (Jan 16, 2025):
That is the implication indeed at the moment.
Not sure if we will adjust that in the future.
@brianjmurrell commented on GitHub (Jan 17, 2025):
I will submit a PR for the RPM packaging to set the version variable in the
vaultwardenprocess's environment when started by the systemd unit file then. Thanks for the info.Back to the passkey creation problem though, it works in two environments on the one computer I ran the subsequent tests above on to try to reproduce the failure I initially reported, so that is good.
But it still fails on the computer I originally filed this issue about. Can you provide any guidance/debugging techniques to try to discover why passkey registration fails on some installations and not others? The only significant difference between the two environments are that the working one is Fedora 40 and the non-working one is Fedora 41, but both are using the latest Chrome with the latest Bitwarden extension, etc.
@brianjmurrell commented on GitHub (Jan 17, 2025):
Hrm. Now it's working in the environment where it was not. Strange.
Thanks for all of your input in any case.
@BlackDex commented on GitHub (Jan 17, 2025):
Setting it in systemd will not work. It needs to be done during build.
It will not work in runtime.
@brianjmurrell commented on GitHub (Jan 17, 2025):
Ahh. I misunderstood where that check was being done.
Thanks for the clarification.
@brianjmurrell commented on GitHub (Feb 3, 2025):
Just to close the loop on this, setting the
$VW_VERSIONduring the build does seem to correct the issue with generating the support string.