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/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
Go to github.com -> Settings -> Passwords & Authentication -> Add a passkey
Click on Add passkey button
Choose a login to save the passkey to
Click Save passkey
Expected Result
Passkey should be saved.
Actual Result
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

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

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.
GiteaMirror
added the bug label 2025-11-07 07:34:49 -06:00
@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
```
@brianjmurrell commented on GitHub (Jan 16, 2025):
Same kinds of errors (without any devtools console errors however) on passkeys.io:
@brianjmurrell commented on GitHub (Jan 16, 2025):
Same kinds of errors (without any devtools console errors however) on passkeys.io:

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.
@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:
It doesn't load the Javascript files probably
DevTools seems to show it seems to be loading JS files:
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):
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:

> It doesn't load the Javascript files probably
DevTools seems to show it seems to be loading JS files:

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

> 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.
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.
@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?
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.
@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
@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?
@brianjmurrell commented on GitHub (Jan 16, 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 16, 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 16, 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 16, 2025):
Hrm. Now it's working in the environment where it was not. Strange.
Thanks for all of your input in any case.
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 16, 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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.
https://github.com/dani-garcia/vaultwarden/blob/29f2b433f01851ef007e893b6e4f7500b4f987de/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 16, 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 16, 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 16, 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 16, 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.