[GH-ISSUE #3776] WebSocket notifications require access_token query parameter #18439

New Issue

GiteaMirror · 2026-04-25T20:36:52-05:00

GiteaMirror commented

2026-04-25 20:36:52 -05:00

Originally created by @AChep on GitHub (Aug 14, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/3776

Originally assigned to: @BlackDex on GitHub.

Subject of the issue

Looking at the updated WebSocket notifications implementation, we explicitly check for the access_token parameter here: 3dbfc484a5/src/api/notifications.rs (L86)

While this is correct most of the time, the token can actually be passed with Authorization Bearer token!
ts: 721cd72b62/src/SignalR/clients/ts/signalr/src/WebSocketTransport.ts (L55)
java: 721cd72b62/src/SignalR/clients/java/signalr/core/src/main/java/com/microsoft/signalr/WebSocketTransport.java (L48)

Expected behaviour

Access token is derived from either query params or bearer header.

Actual behaviour

Access token is derived from only query params.

Originally created by @AChep on GitHub (Aug 14, 2023). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/3776 Originally assigned to: @BlackDex on GitHub. ### Subject of the issue Looking at the updated WebSocket notifications implementation, we explicitly check for the `access_token` parameter here: https://github.com/BlackDex/vaultwarden/blob/3dbfc484a54c41d1759646444b439da06445060b/src/api/notifications.rs#L86 While this is correct most of the time, the token can actually be passed with Authorization Bearer token! ts: https://github.com/dotnet/aspnetcore/blob/721cd72b627bb43f4f9d7988662fbc5f26c46167/src/SignalR/clients/ts/signalr/src/WebSocketTransport.ts#L55 java: https://github.com/dotnet/aspnetcore/blob/721cd72b627bb43f4f9d7988662fbc5f26c46167/src/SignalR/clients/java/signalr/core/src/main/java/com/microsoft/signalr/WebSocketTransport.java#L48 ### Expected behaviour Access token is derived from either query params or bearer header. ### Actual behaviour Access token is derived from only query params.

GiteaMirror added the enhancement label 2026-04-25 20:36:52 -05:00

GiteaMirror closed this issue

2026-04-25 20:36:53 -05:00

GiteaMirror commented

2026-04-25 20:36:54 -05:00

@AChep commented on GitHub (Aug 14, 2023):

This issue currently prevents my Bitwarden client Keyguard from connecting to the server, as SignalR Java implementation always passes access token via headers.

@AChep commented on GitHub (Aug 14, 2023): This issue currently prevents my Bitwarden client Keyguard from connecting to the server, as SignalR Java implementation always passes access token via headers.

GiteaMirror commented

2026-04-25 20:36:54 -05:00

@BlackDex commented on GitHub (Aug 14, 2023):

Looks like Bitwarden it self checks both indeed.
We would need to add a check if the access_token isn't there, then check the Authorization header.

Thanks for reporting.

@BlackDex commented on GitHub (Aug 14, 2023): Looks like Bitwarden it self checks both indeed. We would need to add a check if the access_token isn't there, then check the `Authorization` header. Thanks for reporting.

GiteaMirror commented

2026-04-25 20:36:55 -05:00

@BlackDex commented on GitHub (Aug 27, 2023):

Well, i fixed the auth-check, but sync doesn't work, as it seems to not understand the response we send.
The app tells me the sync failed.

Probably something in the json data, but i'm not sure what it could be right now.

@BlackDex commented on GitHub (Aug 27, 2023): Well, i fixed the auth-check, but sync doesn't work, as it seems to not understand the response we send. The app tells me the sync failed. Probably something in the json data, but i'm not sure what it could be right now.

GiteaMirror commented

2026-04-25 20:36:55 -05:00

@AChep commented on GitHub (Aug 27, 2023):

Well, i fixed the auth-check, but sync doesn't work, as it seems to not understand the response we send.
But, the app tells me the sync failed.

Probably something in the json data, but i'm not sure what it could be right now.

Hmm, that is interesting. Do you test with a personal vault or is there any chance I could grab that data to test it on my end?

What is the sync error that it shows?

@AChep commented on GitHub (Aug 27, 2023): > Well, i fixed the auth-check, but sync doesn't work, as it seems to not understand the response we send. > But, the app tells me the sync failed. > > Probably something in the json data, but i'm not sure what it could be right now. Hmm, that is interesting. Do you test with a personal vault or is there any chance I could grab that data to test it on my end? What is the sync error that it shows?

GiteaMirror commented

2026-04-25 20:36:55 -05:00

@BlackDex commented on GitHub (Aug 27, 2023):

It's just a vault using Vaultwarden. Nothing more or less.
I have not yet tried with a personal only account, not linked to org's.
The current one i used was one linked to several org's.

I first thought it had to do with the casing of the json response, but that wasn't an issue either.

There is no specific message shown in the app, maybe there is some debug setting?
Also, did not checked adb logcat.

@BlackDex commented on GitHub (Aug 27, 2023): It's just a vault using Vaultwarden. Nothing more or less. I have not yet tried with a personal only account, not linked to org's. The current one i used was one linked to several org's. I first thought it had to do with the casing of the json response, but that wasn't an issue either. There is no specific message shown in the app, maybe there is some debug setting? Also, did not checked `adb logcat`.

GiteaMirror commented

2026-04-25 20:36:55 -05:00

@AChep commented on GitHub (Aug 27, 2023):

It's just a vault using Vaultwarden. Nothing more or less.
I have not yet tried with a personal only account, not linked to org's.
The current one i used was one linked to several org's.

I first thought it had to do with the casing of the json response, but that wasn't an issue either.

There is no specific message shown in the app, maybe there is some debug setting?
Also, did not checked adb logcat.

Any chance you could grab a logcat? I think it might contain the original exception. Or I could send you a dev build tomorrow that has more logs in it, if that's fine for you. Thanks! 🙏

The sync exception is definitely due to the app not being able to parse the sync response, not because of the sockets. So there's something unusual in your vault that I didn't account for.

@AChep commented on GitHub (Aug 27, 2023): > It's just a vault using Vaultwarden. Nothing more or less. > I have not yet tried with a personal only account, not linked to org's. > The current one i used was one linked to several org's. > > I first thought it had to do with the casing of the json response, but that wasn't an issue either. > > There is no specific message shown in the app, maybe there is some debug setting? > Also, did not checked `adb logcat`. Any chance you could grab a logcat? I think it might contain the original exception. Or I could send you a dev build tomorrow that has more logs in it, if that's fine for you. Thanks! 🙏 The sync exception is definitely due to the app not being able to parse the sync response, not because of the sockets. So there's something unusual in your vault that I didn't account for.

GiteaMirror commented

2026-04-25 20:36:55 -05:00

@BlackDex commented on GitHub (Aug 27, 2023):

Looks like some value we send as null, or maybe not at all which breaks it.
These are cryptic messages for me, but hopefully it helps you :).

08-27 22:12:50.102  4338 11236 I System.out: exception first
08-27 22:12:50.102  4338 11236 I System.out: exception second
08-27 22:12:50.127  4338 11236 I System.out: exception
08-27 22:12:50.173  4338 11236 I System.out: then
08-27 22:12:50.173  4338 11236 I System.out: message null
08-27 22:12:50.189  4338  4447 I WM-WorkerWrapper: Worker result FAILURE for Work [ id=66d90458-4273-49ab-9efe-6754d8e32a84, tags={ com.artemchep.keyguard.android.worker.SyncWorker } ]
08-27 22:12:50.265  4338  4348 I emchep.keyguard: Background concurrent copying GC freed 569100(26MB) AllocSpace objects, 313(46MB) LOS objects, 75% free, 21MB/84MB, paused 75us,43us total 113.944ms

@BlackDex commented on GitHub (Aug 27, 2023): Looks like some value we send as `null`, or maybe not at all which breaks it. These are cryptic messages for me, but hopefully it helps you :). ``` 08-27 22:12:50.102 4338 11236 I System.out: exception first 08-27 22:12:50.102 4338 11236 I System.out: exception second 08-27 22:12:50.127 4338 11236 I System.out: exception 08-27 22:12:50.173 4338 11236 I System.out: then 08-27 22:12:50.173 4338 11236 I System.out: message null 08-27 22:12:50.189 4338 4447 I WM-WorkerWrapper: Worker result FAILURE for Work [ id=66d90458-4273-49ab-9efe-6754d8e32a84, tags={ com.artemchep.keyguard.android.worker.SyncWorker } ] 08-27 22:12:50.265 4338 4348 I emchep.keyguard: Background concurrent copying GC freed 569100(26MB) AllocSpace objects, 313(46MB) LOS objects, 75% free, 21MB/84MB, paused 75us,43us total 113.944ms ```

GiteaMirror commented

2026-04-25 20:36:56 -05:00

@AChep commented on GitHub (Aug 28, 2023):

@BlackDex this is indeed due to app failing to parse the JSON from the server. Could you please check this build? https://drive.google.com/file/d/1AqSTu22Ut4oZgHNOr7ChtpHEPG0uxi7o/view?usp=sharing The log should be right after "Sanitized response json:" line.

@AChep commented on GitHub (Aug 28, 2023): @BlackDex this is indeed due to app failing to parse the JSON from the server. Could you please check this build? https://drive.google.com/file/d/1AqSTu22Ut4oZgHNOr7ChtpHEPG0uxi7o/view?usp=sharing The log should be right after "Sanitized response json:" line.

GiteaMirror commented

2026-04-25 20:36:56 -05:00

@BlackDex commented on GitHub (Aug 28, 2023):

That made it clear.
The problem is the following, i seem to have 2 SecureNote entries which do not have a type defined.
It should look like this:

  "secureNote": { "type": 0 },

But for those two items it looks like:

  "secureNote": {},

Because, that is how it is stored in the database, else it would have returned null instead if there was nothing.
The strange thing is, we do not change anything on that specific field, we just store it as it is received (except maybe for removing a key called Response). It might be that some older versions of Bitwarden didn't created those entries, or it had something to do with import.

Edit:
btw, you should be able to replicate this your self by just editing the database look for a type 2 cipher, and update the data column with just {}.

Edit2:
I quickly tested it btw by fixing those entries, and it sync just nice.

@BlackDex commented on GitHub (Aug 28, 2023): That made it clear. The problem is the following, i seem to have 2 SecureNote entries which do not have a `type` defined. It should look like this: ```json "secureNote": { "type": 0 }, ``` But for those two items it looks like: ```json "secureNote": {}, ``` Because, that is how it is stored in the database, else it would have returned `null` instead if there was nothing. The strange thing is, we do not change anything on that specific field, we just store it as it is received (except maybe for removing a key called `Response`). It might be that some older versions of Bitwarden didn't created those entries, or it had something to do with import. Edit: btw, you should be able to replicate this your self by just editing the database look for a `type` `2` cipher, and update the `data` column with just `{}`. Edit2: I quickly tested it btw by fixing those entries, and it sync just nice.

GiteaMirror commented

2026-04-25 20:36:57 -05:00

@AChep commented on GitHub (Aug 28, 2023):

Thanks for debugging it! I was able to fix it on my end.

@AChep commented on GitHub (Aug 28, 2023): Thanks for debugging it! I was able to fix it on my end.

GiteaMirror commented

2026-04-25 20:36:58 -05:00

@Laibalion commented on GitHub (Aug 28, 2023):

Is this the same issue as what I'm seeing? In my Vaultwarden container logs I'm seeing

2023/08/28 14:56:20 stdout [2023-08-28 12:56:20.068][vaultwarden::api::core::accounts][ERROR] An error occured while proceeding registration of a device: {"ErrorModel":{"Message":"Unexpected push token received from bitwarden server: error decoding response body: missing field access_token at line 1 column 26","Object":"error"},"ExceptionMessage":null,"ExceptionStackTrace":null,"InnerExceptionMessage":null,"Message":"Unexpected push token received from bitwarden server: error decoding response body: missing field access_token at line 1 column 26","Object":"error","ValidationErrors":{"":["Unexpected push token received from bitwarden server: error decoding response body: missing field access_token at line 1 column 26"]},"error":"","error_description":""}

2023/08/28 14:56:20 stdout [2023-08-28 12:56:20.068][vaultwarden::api::push][ERROR] Unexpected push token received from bitwarden server: error decoding response body: missing field access_token at line 1 column 26

Needless to mention I guess that the push notifications aren't working.
PUSH_ENABLED, PUSH_INSTALLATION_KEY and PUSH_INSTALLATION_ID are being set via my container's Environement variables.

@Laibalion commented on GitHub (Aug 28, 2023): Is this the same issue as what I'm seeing? In my Vaultwarden container logs I'm seeing > 2023/08/28 14:56:20 | stdout | [2023-08-28 12:56:20.068][vaultwarden::api::core::accounts][ERROR] An error occured while proceeding registration of a device: {"ErrorModel":{"Message":"Unexpected push token received from bitwarden server: error decoding response body: missing field `access_token` at line 1 column 26","Object":"error"},"ExceptionMessage":null,"ExceptionStackTrace":null,"InnerExceptionMessage":null,"Message":"Unexpected push token received from bitwarden server: error decoding response body: missing field `access_token` at line 1 column 26","Object":"error","ValidationErrors":{"":["Unexpected push token received from bitwarden server: error decoding response body: missing field `access_token` at line 1 column 26"]},"error":"","error_description":""} -- | -- | -- 2023/08/28 14:56:20 | stdout | [2023-08-28 12:56:20.068][vaultwarden::api::push][ERROR] Unexpected push token received from bitwarden server: error decoding response body: missing field `access_token` at line 1 column 26 Needless to mention I guess that the push notifications aren't working. PUSH_ENABLED, PUSH_INSTALLATION_KEY and PUSH_INSTALLATION_ID are being set via my container's Environement variables.

GiteaMirror commented

2026-04-25 20:36:58 -05:00

@BlackDex commented on GitHub (Aug 28, 2023):

@Laibalion , no that has nothing to do with this issue.
There are other issues/discussion regarding this.

There are two items which probably is the issue in your case.

You reversed the key and id in the config.
You used a EU key/id while Vaultwarden only supports US.

For all other discussions i would suggest too look here: https://github.com/dani-garcia/vaultwarden/discussions/2469

@BlackDex commented on GitHub (Aug 28, 2023): @Laibalion , no that has nothing to do with this issue. There are other issues/discussion regarding this. There are two items which probably is the issue in your case. 1. You reversed the key and id in the config. 2. You used a EU key/id while Vaultwarden only supports US. For all other discussions i would suggest too look here: https://github.com/dani-garcia/vaultwarden/discussions/2469

GiteaMirror commented

2026-04-25 20:36:58 -05:00

@Laibalion commented on GitHub (Aug 28, 2023):

Oh, my bad. Was indeed using EU key/id :|
Thanks for the info.

@Laibalion commented on GitHub (Aug 28, 2023): Oh, my bad. Was indeed using EU key/id :| Thanks for the info.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#18439

[GH-ISSUE #3776] WebSocket notifications require access_token query parameter #18439

Subject of the issue

Expected behaviour

Actual behaviour

[GH-ISSUE #3776] WebSocket notifications require `access_token` query parameter #18439