Creating passkeys fails: Uncaught (in promise) Error: The operation either timed out or was not allowed. #2131

Closed
opened 2026-02-05 03:22:06 +03:00 by OVERLORD · 14 comments
Owner

Originally created by @brianjmurrell on GitHub (Jan 16, 2025).

Vaultwarden Support String

Nothing happens when I click on the
image
button. Developer tools console in the browser doesn't even show anything new.

On reloading that /admin/diagnostics page however the console does report:

Error with Permissions-Policy header: Unrecognized feature: 'ambient-light-sensor'.
Error with Permissions-Policy header: Unrecognized feature: 'battery'.
Error with Permissions-Policy header: Unrecognized feature: 'document-domain'.
Error with Permissions-Policy header: Unrecognized feature: 'execution-while-not-rendered'.
Error with Permissions-Policy header: Unrecognized feature: 'execution-while-out-of-viewport'.
Error with Permissions-Policy header: Unrecognized feature: 'web-share'.
Navigated to https://vw.interlinx.bc.ca:56443/admin/diagnostics
admin_diagnostics.js:201 Uncaught TypeError: Cannot read properties of null (reading 'indexOf')
    at initVersionCheck (admin_diagnostics.js:201:25)
    at init (admin_diagnostics.js:400:5)
    at HTMLDocument.<anonymous> (admin_diagnostics.js:415:5)

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

  1. Go to github.com -> Settings -> Passwords & Authentication -> Add a passkey
  2. Click on Add passkey button
  3. Choose a login to save the passkey to
  4. Click Save passkey

Expected Result

Passkey should be saved.

Actual Result

image

Devtools console reports:

fido2-page-script.js:294 Uncaught (in promise) Error: The operation either timed out or was not allowed.
    at Messenger.<anonymous> (fido2-page-script.js:294:35)
    at Generator.next (<anonymous>)
    at fulfilled (fido2-page-script.js:230:58)

Logs

Jan 15 20:33:04 vaultwarden[2900454]: [2025-01-15 20:33:04.077][request][INFO] POST /identity/connect/token
Jan 15 20:33:04 vaultwarden[2900454]: [2025-01-15 20:33:04.080][response][INFO] (login) POST /identity/connect/token => 400 Bad Request
Jan 15 20:33:07 vaultwarden[2900454]: [2025-01-15 20:33:07.151][request][INFO] POST /identity/connect/token
Jan 15 20:33:07 vaultwarden[2900454]: [2025-01-15 20:33:07.151][response][INFO] (login) POST /identity/connect/token => 400 Bad Request

Screenshots or Videos

No response

Additional Context

Passkeys add fine using the same browser, extension, etc. when using the bitwarden.com vault server.

Originally created by @brianjmurrell on GitHub (Jan 16, 2025). ### Vaultwarden Support String Nothing happens when I click on the ![image](https://github.com/user-attachments/assets/ee54c927-5bdf-4e8f-a8f6-3801cf42800b) button. Developer tools console in the browser doesn't even show anything new. On reloading that `/admin/diagnostics` page however the console does report: ``` Error with Permissions-Policy header: Unrecognized feature: 'ambient-light-sensor'. Error with Permissions-Policy header: Unrecognized feature: 'battery'. Error with Permissions-Policy header: Unrecognized feature: 'document-domain'. Error with Permissions-Policy header: Unrecognized feature: 'execution-while-not-rendered'. Error with Permissions-Policy header: Unrecognized feature: 'execution-while-out-of-viewport'. Error with Permissions-Policy header: Unrecognized feature: 'web-share'. Navigated to https://vw.interlinx.bc.ca:56443/admin/diagnostics admin_diagnostics.js:201 Uncaught TypeError: Cannot read properties of null (reading 'indexOf') at initVersionCheck (admin_diagnostics.js:201:25) at init (admin_diagnostics.js:400:5) at HTMLDocument.<anonymous> (admin_diagnostics.js:415:5) ``` 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 1. Go to github.com -> Settings -> Passwords & Authentication -> Add a passkey 2. Click on Add passkey button 3. Choose a login to save the passkey to 4. Click Save passkey ### Expected Result Passkey should be saved. ### Actual Result ![image](https://github.com/user-attachments/assets/dffdf724-025d-468e-9489-2d881dbe9a07) Devtools console reports: ``` fido2-page-script.js:294 Uncaught (in promise) Error: The operation either timed out or was not allowed. at Messenger.<anonymous> (fido2-page-script.js:294:35) at Generator.next (<anonymous>) at fulfilled (fido2-page-script.js:230:58) ``` ### Logs ```text Jan 15 20:33:04 vaultwarden[2900454]: [2025-01-15 20:33:04.077][request][INFO] POST /identity/connect/token Jan 15 20:33:04 vaultwarden[2900454]: [2025-01-15 20:33:04.080][response][INFO] (login) POST /identity/connect/token => 400 Bad Request Jan 15 20:33:07 vaultwarden[2900454]: [2025-01-15 20:33:07.151][request][INFO] POST /identity/connect/token Jan 15 20:33:07 vaultwarden[2900454]: [2025-01-15 20:33:07.151][response][INFO] (login) POST /identity/connect/token => 400 Bad Request ``` ### Screenshots or Videos _No response_ ### Additional Context Passkeys add fine using the same browser, extension, etc. when using the bitwarden.com vault server.
OVERLORD added the bug label 2026-02-05 03:22:06 +03:00
Author
Owner

@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:

Jan 15 20:59:17 vaultwarden[2900454]: [2025-01-15 20:59:17.294][request][INFO] POST /identity/connect/token
Jan 15 20:59:17 vaultwarden[2900454]: [2025-01-15 20:59:17.295][response][INFO] (login) POST /identity/connect/token => 400 Bad Request
Jan 15 20:59:18 vaultwarden[2900454]: [2025-01-15 20:59:18.449][request][INFO] POST /identity/connect/token
Jan 15 20:59:18 vaultwarden[2900454]: [2025-01-15 20:59:18.449][response][INFO] (login) POST /identity/connect/token => 400 Bad Request
@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: ``` Jan 15 20:59:17 vaultwarden[2900454]: [2025-01-15 20:59:17.294][request][INFO] POST /identity/connect/token Jan 15 20:59:17 vaultwarden[2900454]: [2025-01-15 20:59:17.295][response][INFO] (login) POST /identity/connect/token => 400 Bad Request Jan 15 20:59:18 vaultwarden[2900454]: [2025-01-15 20:59:18.449][request][INFO] POST /identity/connect/token Jan 15 20:59:18 vaultwarden[2900454]: [2025-01-15 20:59:18.449][response][INFO] (login) POST /identity/connect/token => 400 Bad Request ```
Author
Owner

@brianjmurrell commented on GitHub (Jan 16, 2025):

Same kinds of errors (without any devtools console errors however) on passkeys.io:

image

@brianjmurrell commented on GitHub (Jan 16, 2025): Same kinds of errors (without any devtools console errors however) on passkeys.io: ![image](https://github.com/user-attachments/assets/dd523ce0-56d6-4b46-9d98-3ba8c49a50b7)
Author
Owner

@BlackDex commented on GitHub (Jan 16, 2025):

The /admin/diagnostics page 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/token returns 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 nojs or 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.

@BlackDex commented on GitHub (Jan 16, 2025): The `/admin/diagnostics` page 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/token` returns 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 `nojs` or 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.
Author
Owner

@brianjmurrell commented on GitHub (Jan 16, 2025):

The /admin/diagnostics page doesn't even look how it should look.

No? I did only paste a portion of it. The entire page looks like:

Image

It doesn't load the Javascript files probably

DevTools seems to show it seems to be loading JS files:

Image

or something else is breaking your environment, like extensions in the browser which break stuff.

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

Image

I suspect that your reverse proxy or tunnel provider

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.

some security extensions could cause issues like nojs or extensions which clear local storage or prevent cookies or other headers.

I don't have any extensions of that sort that I am aware of.

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.

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/diagnostics page's Generate Support String not working if you wish.

@brianjmurrell commented on GitHub (Jan 16, 2025): > The `/admin/diagnostics` page doesn't even look how it should look. No? I did only paste a portion of it. The entire page looks like: ![Image](https://github.com/user-attachments/assets/6e9261ef-e289-41fc-ab1d-9c514bd1bd32) > It doesn't load the Javascript files probably DevTools seems to show it seems to be loading JS files: ![Image](https://github.com/user-attachments/assets/c967e37f-0a8b-4655-ad68-719bd2936106) > or something else is breaking your environment, like extensions in the browser which break stuff. 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): ![Image](https://github.com/user-attachments/assets/148f1ea0-7640-483b-97d1-5552158670a9) > I suspect that your reverse proxy or tunnel provider 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. > some _security_ extensions could cause issues like `nojs` or extensions which clear local storage or prevent cookies or other headers. I don't have any extensions of that sort that I am aware of. > 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. 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/diagnostics` page's _Generate Support String_ not working if you wish.
Author
Owner

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

@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.
Author
Owner

@brianjmurrell 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.

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?

@brianjmurrell 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. 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?
Author
Owner

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

@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. https://github.com/dani-garcia/vaultwarden/blob/29f2b433f01851ef007e893b6e4f7500b4f987de/build.rs#L37-L40
Author
Owner

@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_VERSION env. variable in vaultwarden's environment for such builds?

@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_VERSION` env. variable in `vaultwarden`'s environment for such builds?
Author
Owner

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

@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.
Author
Owner

@brianjmurrell commented on GitHub (Jan 17, 2025):

I will submit a PR for the RPM packaging to set the version variable in the vaultwarden process'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): I will submit a PR for the RPM packaging to set the version variable in the `vaultwarden` process'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.
Author
Owner

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

@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.
Author
Owner

@BlackDex commented on GitHub (Jan 17, 2025):

I will submit a PR for the RPM packaging to set the version variable in the vaultwarden process's environment when started by the systemd unit file then. Thanks for the info.

Setting it in systemd will not work. It needs to be done during build.
It will not work in runtime.

@BlackDex commented on GitHub (Jan 17, 2025): > I will submit a PR for the RPM packaging to set the version variable in the `vaultwarden` process's environment when started by the systemd unit file then. Thanks for the info. > Setting it in systemd will not work. It needs to be done during build. It will not work in runtime.
Author
Owner

@brianjmurrell commented on GitHub (Jan 17, 2025):

Ahh. I misunderstood where that check was being done.

Thanks for the clarification.

@brianjmurrell commented on GitHub (Jan 17, 2025): Ahh. I misunderstood where that check was being done. Thanks for the clarification.
Author
Owner

@brianjmurrell commented on GitHub (Feb 3, 2025):

Just to close the loop on this, setting the $VW_VERSION during the build does seem to correct the issue with generating the support string.

@brianjmurrell commented on GitHub (Feb 3, 2025): Just to close the loop on this, setting the `$VW_VERSION` during the build does seem to correct the issue with generating the support string.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#2131