[GH-ISSUE #5237 ] Android bitwarden app stopped having access to vault #2103

Author

Owner

@BlackDex commented on GitHub (Nov 27, 2024):

I would not recommend to revert to an older version. Mainly because of security bugs. Also the latest version should have better fixes for the new native clients and sound work better.

If it doesn't work, I would need more info.
See https://github.com/dani-garcia/vaultwarden/issues/4870#issuecomment-2306749481 on how to extract these details for me.

@BlackDex commented on GitHub (Nov 27, 2024): I would not recommend to revert to an older version. Mainly because of security bugs. Also the latest version should have better fixes for the new native clients and sound work better. If it doesn't work, I would need more info. See https://github.com/dani-garcia/vaultwarden/issues/4870#issuecomment-2306749481 on how to extract these details for me.

kerem commented

Author

Owner

@diagpope commented on GitHub (Nov 27, 2024):

This is the version from the Google Play store that did not work

User-Agent: Bitwarden_Mobile/2024.11.6 (release/standard) (Android 11; SDK 30; Model motorola one 5G ace)^M

The log file produced with sudo tcpflow -i any -C port 80 on the failed access is
tcpflow.broken.gz

Then I installed from https://github.com/bitwarden/mobile/releases this version:
Version 2024.7.1

Access to the vault was restored. log file produced with sudo tcpflow -i any -C port 80 on the successful access is
tcpflow.success.gz

How can I self diagnose this next time?

@diagpope commented on GitHub (Nov 27, 2024): This is the version from the Google Play store that did not work ``` User-Agent: Bitwarden_Mobile/2024.11.6 (release/standard) (Android 11; SDK 30; Model motorola one 5G ace)^M ``` The log file produced with `sudo tcpflow -i any -C port 80` on the failed access is [tcpflow.broken.gz](https://github.com/user-attachments/files/17941109/tcpflow.broken.gz) Then I installed from https://github.com/bitwarden/mobile/releases this version: [Version 2024.7.1](https://github.com/bitwarden/mobile/releases/tag/v2024.7.1) Access to the vault was restored. log file produced with `sudo tcpflow -i any -C port 80` on the successful access is [tcpflow.success.gz](https://github.com/user-attachments/files/17941112/tcpflow.success.gz) How can I self diagnose this next time?

kerem commented

Author

Owner

@mindonwarp commented on GitHub (Nov 28, 2024):

The configuration that is now working for me:

Vaultwarden version 1.32.5
Proxy: jc21/nginx-proxy-manager:2
Bitwarden App: 2024.11.5 (19461)

@mindonwarp commented on GitHub (Nov 28, 2024): The configuration that is now working for me: - Vaultwarden version 1.32.5 - Proxy: jc21/nginx-proxy-manager:2 - Bitwarden App: 2024.11.5 (19461)

kerem commented

Author

Owner

@BlackDex commented on GitHub (Nov 28, 2024):

@dombrowa the version you are using now is not the native client.
Those can be found at the bitwarden/android repo not the bitwarden/mobile.

I'll have to shift through the data and see if i can give anything which might break the client. But that isn't going to be easy.

Something in te response of the server, most likely the sync request is sending something the native clients do not support our crash on. What this is exactly isn't easy to tell. Since I'm not able to reproduce this my self.

@BlackDex commented on GitHub (Nov 28, 2024): @dombrowa the version you are using now is not the native client. Those can be found at the `bitwarden/android` repo not the `bitwarden/mobile`. I'll have to shift through the data and see if i can give anything which might break the client. But that isn't going to be easy. Something in te response of the server, most likely the sync request is sending something the native clients do not support our crash on. What this is exactly isn't easy to tell. Since I'm not able to reproduce this my self.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Nov 28, 2024):

@dombrowa Unfortunately those tcpflows are not useful for me.
I think you tried to remove some sensitive data, which mangled the whole json. If I'm not able to see the json in it's original form i can't try to debug this. It will take me to much time, and i can't tell if there is something wrong with Vaultwarden, or if it is something deleted/mangled by you.

@BlackDex commented on GitHub (Nov 28, 2024): @dombrowa Unfortunately those tcpflows are not useful for me. I think you tried to remove some sensitive data, which mangled the whole json. If I'm not able to see the json in it's original form i can't try to debug this. It will take me to much time, and i can't tell if there is something wrong with Vaultwarden, or if it is something deleted/mangled by you.

kerem commented

Author

Owner

@diamondtipdr commented on GitHub (Nov 28, 2024):

I tried the android Bitwarden native app (as part of the beta in the Play Store), and it didn't like my VW instance. Had to change back to the standard version available in the Store (2024.10.0 11270) for it to work.

@diamondtipdr commented on GitHub (Nov 28, 2024): I tried the android Bitwarden native app (as part of the beta in the Play Store), and it didn't like my VW instance. Had to change back to the standard version available in the Store (2024.10.0 11270) for it to work.

kerem commented

Author

Owner

@diagpope commented on GitHub (Nov 29, 2024):

@BlackDex
The command I used to capture was:

sudo tcpflow -i any -C port 80 | tee ~/tcpflow.xxx

Then, I only used sed commands to redact text as such:

sed -i 's/<before>/redacteddomain/g' $@

Is there a better way to capture traces?

When I look at the log files, they seem to contain mostly HTTP headers that are not json, and only a few lines of json that can be parsed via jq (example below)

echo '{"environment":{"api":"http://localhost/api","identity":"http://localhost/identity","notifications":"http://localhost/notifications","sso":"","vault":"http://localhost"},"featureStates":{"fido2-vault-credentials":true,"flexible-collections-v-1":false,"key-rotation-improvements":true},"gitHash":"cdfdc6ff","object":"config","server":{"name":"Vaultwarden","url":"https://github.com/dani-garcia/vaultwarden"},"settings":{"disableUserRegistration":true},"version":"2024.2.0"}' | jq .
{
  "environment": {
    "api": "http://localhost/api",
    "identity": "http://localhost/identity",
    "notifications": "http://localhost/notifications",
    "sso": "",
    "vault": "http://localhost"
  },
  "featureStates": {
    "fido2-vault-credentials": true,
    "flexible-collections-v-1": false,
    "key-rotation-improvements": true
  },
  "gitHash": "cdfdc6ff",
  "object": "config",
  "server": {
    "name": "Vaultwarden",
    "url": "https://github.com/dani-garcia/vaultwarden"
  },
  "settings": {
    "disableUserRegistration": true
  },
  "version": "2024.2.0"
}

@diagpope commented on GitHub (Nov 29, 2024): @BlackDex The command I used to capture was: ``` sudo tcpflow -i any -C port 80 | tee ~/tcpflow.xxx ``` Then, I only used sed commands to redact text as such: ``` sed -i 's/<before>/redacteddomain/g' $@ ``` Is there a better way to capture traces? When I look at the log files, they seem to contain mostly HTTP headers that are not json, and only a few lines of json that can be parsed via jq (example below) ``` echo '{"environment":{"api":"http://localhost/api","identity":"http://localhost/identity","notifications":"http://localhost/notifications","sso":"","vault":"http://localhost"},"featureStates":{"fido2-vault-credentials":true,"flexible-collections-v-1":false,"key-rotation-improvements":true},"gitHash":"cdfdc6ff","object":"config","server":{"name":"Vaultwarden","url":"https://github.com/dani-garcia/vaultwarden"},"settings":{"disableUserRegistration":true},"version":"2024.2.0"}' | jq . { "environment": { "api": "http://localhost/api", "identity": "http://localhost/identity", "notifications": "http://localhost/notifications", "sso": "", "vault": "http://localhost" }, "featureStates": { "fido2-vault-credentials": true, "flexible-collections-v-1": false, "key-rotation-improvements": true }, "gitHash": "cdfdc6ff", "object": "config", "server": { "name": "Vaultwarden", "url": "https://github.com/dani-garcia/vaultwarden" }, "settings": { "disableUserRegistration": true }, "version": "2024.2.0" } ```

kerem commented

Author

Owner

@diagpope commented on GitHub (Nov 29, 2024):

The configuration that is now working for me:

Vaultwarden version 1.32.5

Proxy: jc21/nginx-proxy-manager:2

Bitwarden App: 2024.11.5 (19461)

Interesting, when I ran

Vaultwarden version 1.32.5, image: vaultwarden/server:latest
Proxy: image: caddy:2
Bitwarden App: 2024.11.6

I encountered the failure.
Either the android client or the combination of android client and proxy caused the problem on android mobile.
It seemed to work in iOS which I do not use.

@diagpope commented on GitHub (Nov 29, 2024): > The configuration that is now working for me: > > * Vaultwarden version 1.32.5 > * Proxy: jc21/nginx-proxy-manager:2 > * Bitwarden App: 2024.11.5 (19461) Interesting, when I ran * Vaultwarden version 1.32.5, image: vaultwarden/server:latest * Proxy: image: caddy:2 * Bitwarden App: 2024.11.6 I encountered the failure. Either the android client or the combination of android client and proxy caused the problem on android mobile. It seemed to work in iOS which I do not use.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Nov 29, 2024):

The only issue i know of regarding reverse proxies is if they do some security filtering, or override headers.

@dombrowa well, that redaction caused the output to be not useable for me.

The other way would be generating the har file via the browser just on your desktop. There sync output should be exactly the same, so that will be fine. But i would not suggest to put that har file here.
Use the contact options i suggested in the link.

@BlackDex commented on GitHub (Nov 29, 2024): The only issue i know of regarding reverse proxies is if they do some security filtering, or override headers. @dombrowa well, that redaction caused the output to be not useable for me. The other way would be generating the *har* file via the browser just on your desktop. There sync output should be exactly the same, so that will be fine. But i would not suggest to put that har file here. Use the contact options i suggested in the link.

kerem commented

Author

Owner

@diagpope commented on GitHub (Dec 3, 2024):

@BlackDex
Question: If I use my browser on the desktop, I do not encounter the login failure to vaultwarden.
How to I get an har file when using the bitwarden mobile app?

When I run this, I see the not redacted output is not recognized json either:

sudo tcpflow -i any -C port 80 |tee bitwarden.tcpflow.fail | jq .
reportfilename: ./report.xml
tcpflow: listening on any
parse error: Invalid numeric literal at line 1, column 4


Note: I just updated the mobile app on android and am seeing the login failure again.

@diagpope commented on GitHub (Dec 3, 2024): @BlackDex Question: If I use my browser on the desktop, I do not encounter the login failure to vaultwarden. How to I get an har file when using the bitwarden mobile app? When I run this, I see the not redacted output is not recognized json either: ``` sudo tcpflow -i any -C port 80 |tee bitwarden.tcpflow.fail | jq . reportfilename: ./report.xml tcpflow: listening on any parse error: Invalid numeric literal at line 1, column 4 Note: I just updated the mobile app on android and am seeing the login failure again.

kerem commented

Author

Owner

@diagpope commented on GitHub (Dec 3, 2024):

I tried the following versions from https://github.com/bitwarden/android

11.4 
11.0
10.2
9.0 beta
8.1 beta
7.3 beta
7.2
7.1 beta  - which I assumed to be close to the mobile 7.1 below, but ...

only this one below works for my android 11 OS. It is not from the android page but
https://github.com/bitwarden/mobile

Version 2024.7.1.apk

@diagpope commented on GitHub (Dec 3, 2024): I tried the following versions from https://github.com/bitwarden/android ``` 11.4 11.0 10.2 9.0 beta 8.1 beta 7.3 beta 7.2 7.1 beta - which I assumed to be close to the mobile 7.1 below, but ... ``` only this one below works for my android 11 OS. It is not from the android page but https://github.com/bitwarden/mobile ``` Version 2024.7.1.apk ```

kerem commented

Author

Owner

@BlackDex commented on GitHub (Dec 3, 2024):

As mentioned before, everything in /mobile is not the native app.
Only applications in /ios or /android are the native apps.

It doesn't matter if the error occurs or not on your browser, i need the har file which includes an unmodified response of the sync request done by the client. The response of Vaultwarden will be exactly the same (at least until v2024.12 is out) for each client.

Without that, I'm not able to do any checking at all.

@BlackDex commented on GitHub (Dec 3, 2024): As mentioned before, everything in `/mobile` is not the native app. Only applications in `/ios` or `/android` are the native apps. It doesn't matter if the error occurs or not on your browser, i need the **har** file which includes an unmodified response of the sync request done by the client. The response of Vaultwarden will be exactly the same (at least until v2024.12 is out) for each client. Without that, I'm not able to do any checking at all.

kerem commented

Author

Owner

@JunfXiao commented on GitHub (Dec 3, 2024):

As mentioned before, everything in /mobile is not the native app. Only applications in /ios or /android are the native apps.

It doesn't matter if the error occurs or not on your browser, i need the har file which includes an unmodified response of the sync request done by the client. The response of Vaultwarden will be exactly the same (at least until v2024.12 is out) for each client.

Without that, I'm not able to do any checking at all.

Hi, here's the har file for your reference:
https://1drv.ms/u/s!ArsqJ8_aARYGoocbnG9BnICVpo3XXA?e=la3ISu

It seems that the server cannot communicate with the official bitwarden server for push token when the client requested it with /identify/connect/token request body. The message:

Unexcepted push token received from bitwarden server: error decoding response body.

from here:
github.com/dani-garcia/vaultwarden@da3701c0cf/src/api/push.rs (L66-L69)

Is there a way to exam what it really got from official server?

@JunfXiao commented on GitHub (Dec 3, 2024): > As mentioned before, everything in `/mobile` is not the native app. Only applications in `/ios` or `/android` are the native apps. > > It doesn't matter if the error occurs or not on your browser, i need the **har** file which includes an unmodified response of the sync request done by the client. The response of Vaultwarden will be exactly the same (at least until v2024.12 is out) for each client. > > Without that, I'm not able to do any checking at all. Hi, here's the har file for your reference: https://1drv.ms/u/s!ArsqJ8_aARYGoocbnG9BnICVpo3XXA?e=la3ISu It seems that the server cannot communicate with the official bitwarden server for push token when the client requested it with `/identify/connect/token` request body. The message: ``` Unexcepted push token received from bitwarden server: error decoding response body. ``` from here: https://github.com/dani-garcia/vaultwarden/blob/da3701c0cfa5fb0fe505c18c5f210edb2a71aaf9/src/api/push.rs#L66-L69 Is there a way to exam what it really got from official server?

kerem commented

Author

Owner

@BlackDex commented on GitHub (Dec 3, 2024):

The only way to do that is by putting a reverse proxy like mitmproxy in between Vaultwarden and the internet.

@BlackDex commented on GitHub (Dec 3, 2024): The only way to do that is by putting a reverse proxy like mitmproxy in between Vaultwarden and the internet.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Dec 3, 2024):

Also, i think your issue @JunfXiao has notthing to do with the main issue of this topic.
Please open a discussion not linked to this issue please.

@BlackDex commented on GitHub (Dec 3, 2024): Also, i think your issue @JunfXiao has notthing to do with the main issue of this topic. Please open a discussion not linked to this issue please.

kerem commented

Author

Owner

@diagpope commented on GitHub (Dec 3, 2024):

@BlackDex
I created a har file, clicked Export HAR (sanitized) but noticed that it contains a lots of sensitive data , such as:
masterPasswordHint, full name, full domain, server IP, some vault item IPs
Is there a suggested scrubbing tool?

@diagpope commented on GitHub (Dec 3, 2024): @BlackDex I created a har file, clicked Export HAR (sanitized) but noticed that it contains a lots of sensitive data , such as: masterPasswordHint, full name, full domain, server IP, some vault item IPs Is there a suggested scrubbing tool?

kerem commented

Author

Owner

@BlackDex commented on GitHub (Dec 3, 2024):

No, not really. Scrubbing it will remove data i need to check.
Of course you maye remove the password hint. But other stuff might break the file and causes me to be unable to check and search for possible issues.

That is why i suggested in the posted i linked to to send it either via email, or via matrix chat, at which via matrix is preferred.

I have received multiple of those files already, and it helped to fix issues, and i have no interest in trying to decrypt your data in any way.

@BlackDex commented on GitHub (Dec 3, 2024): No, not really. Scrubbing it will remove data i need to check. Of course you maye remove the password hint. But other stuff might break the file and causes me to be unable to check and search for possible issues. That is why i suggested in the posted i linked to to send it either via email, or via matrix chat, at which via matrix is preferred. I have received multiple of those files already, and it helped to fix issues, and i have no interest in trying to decrypt your data in any way.

kerem commented

Author

Owner

@sleshep commented on GitHub (Dec 5, 2024):

After update caddy(build from latest source), it solve my issue.
May this help you.

@sleshep commented on GitHub (Dec 5, 2024): After update caddy(build from latest source), it solve my issue. May this help you.

kerem commented

Author

Owner

@BlackDex commented on GitHub (Dec 5, 2024):

@sleshep any idea what might have caused the issues then? Which option/feature/bug made caddy break the clients?

@BlackDex commented on GitHub (Dec 5, 2024): @sleshep any idea what might have caused the issues then? Which option/feature/bug made caddy break the clients?

kerem commented

Author

Owner

@sleshep commented on GitHub (Dec 5, 2024):

@sleshep any idea what might have caused the issues then? Which option/feature/bug made caddy break the clients?

I guest it happend during TLS negotiation or something before request arrived vaultwarden, because i can't find any caddy access logs when i press bitwarden android login button.

@sleshep commented on GitHub (Dec 5, 2024): > @sleshep any idea what might have caused the issues then? Which option/feature/bug made caddy break the clients? I guest it happend during TLS negotiation or something before request arrived vaultwarden, because i can't find any caddy access logs when i press bitwarden android login button.

kerem commented

Author

Owner

@diagpope commented on GitHub (Dec 5, 2024):

In my case, a failing setup, there was no update to caddy:latest as of today, was the caddy update a different tag?

latest: Pulling from library/caddy
Digest: sha256:07417b42b03b8929ec80240d1a83e27a9c1346ddbff65988608fd1757269c1eb
Status: Image is up to date for caddy:latest
docker.io/library/caddy:latest

@diagpope commented on GitHub (Dec 5, 2024): In my case, a failing setup, there was no update to caddy:latest as of today, was the caddy update a different tag? ``` latest: Pulling from library/caddy Digest: sha256:07417b42b03b8929ec80240d1a83e27a9c1346ddbff65988608fd1757269c1eb Status: Image is up to date for caddy:latest docker.io/library/caddy:latest ```

kerem commented

Author

Owner

@BlackDex commented on GitHub (Dec 5, 2024):

I have found the issue thanks too two people who provided a har file.
It's a reprompt value in the database which does not equals either NULL, 0, or 1.
In both cases they were 4. How this could have happened I have no idea.

Adjusting that to either of the valid values will resolve the issue.

Now, it could be this is not the case for all other users.
To debug it a bit better, people could download the dev build from the Actions pages, like here: https://github.com/bitwarden/android/actions/runs/12186085669

Install that apk, run it login as usual and see if it still fails.
If that is the case, people should install adb and run adb logcat while there phone is connected via USB or wireless to allow debug access to the phone.

Click on the retry button, and there should be a stack trace somewhere.
That does show a very non-descriptive message which helped to find it.

A better howto should be created i think, but at least the basic steps are described here now.

@BlackDex commented on GitHub (Dec 5, 2024): I have found the issue thanks too two people who provided a `har` file. It's a `reprompt` value in the database which does not equals either `NULL`, `0`, or `1`. In both cases they were `4`. How this could have happened I have no idea. Adjusting that to either of the valid values will resolve the issue. Now, it could be this is not the case for all other users. To debug it a bit better, people could download the `dev` build from the Actions pages, like here: https://github.com/bitwarden/android/actions/runs/12186085669 Install that `apk`, run it login as usual and see if it still fails. If that is the case, people should install `adb` and run `adb logcat` while there phone is connected via USB or wireless to allow debug access to the phone. Click on the retry button, and there should be a stack trace somewhere. That does show a very non-descriptive message which helped to find it. A better howto should be created i think, but at least the basic steps are described here now.

kerem commented

Author

Owner

@306bobby-android commented on GitHub (Dec 8, 2024):

I have found the issue thanks too two people who provided a har file. It's a reprompt value in the database which does not equals either NULL, 0, or 1. In both cases they were 4. How this could have happened I have no idea.

Adjusting that to either of the valid values will resolve the issue.

Now, it could be this is not the case for all other users. To debug it a bit better, people could download the dev build from the Actions pages, like here: https://github.com/bitwarden/android/actions/runs/12186085669

Install that apk, run it login as usual and see if it still fails. If that is the case, people should install adb and run adb logcat while there phone is connected via USB or wireless to allow debug access to the phone.

Click on the retry button, and there should be a stack trace somewhere. That does show a very non-descriptive message which helped to find it.

A better howto should be created i think, but at least the basic steps are described here now.

Here is the network result

12-08 13:44:30.360 W/NetworkResultCall(29074): Network Error: https://api.bitwarden.com/accounts/prelogin
12-08 13:44:30.360 W/NetworkResultCall(29074): kotlinx.serialization.MissingFieldException: Fields [kdf, kdfIterations] are required for type with serial name 'com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson', but they were missing at path: $
12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.platform.datasource.network.serializer.BaseSurrogateSerializer.deserialize(BaseSurrogateSerializer.kt:41)
12-08 13:44:30.360 W/NetworkResultCall(29074): Caused by: kotlinx.serialization.MissingFieldException: Fields [kdf, kdfIterations] are required for type with serial name 'com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson', but they were missing
12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson.(InternalPreLoginResponseJson.kt:11)
12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson.(Unknown Source:0)
12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson$$serializer.deserialize(InternalPreLoginResponseJson.kt:11)
12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson$$serializer.deserialize(InternalPreLoginResponseJson.kt:11)

I can attach more if needed

@306bobby-android commented on GitHub (Dec 8, 2024): > I have found the issue thanks too two people who provided a `har` file. It's a `reprompt` value in the database which does not equals either `NULL`, `0`, or `1`. In both cases they were `4`. How this could have happened I have no idea. > > Adjusting that to either of the valid values will resolve the issue. > > Now, it could be this is not the case for all other users. To debug it a bit better, people could download the `dev` build from the Actions pages, like here: https://github.com/bitwarden/android/actions/runs/12186085669 > > Install that `apk`, run it login as usual and see if it still fails. If that is the case, people should install `adb` and run `adb logcat` while there phone is connected via USB or wireless to allow debug access to the phone. > > Click on the retry button, and there should be a stack trace somewhere. That does show a very non-descriptive message which helped to find it. > > A better howto should be created i think, but at least the basic steps are described here now. Here is the network result 12-08 13:44:30.360 W/NetworkResultCall(29074): Network Error: https://api.bitwarden.com/accounts/prelogin 12-08 13:44:30.360 W/NetworkResultCall(29074): kotlinx.serialization.MissingFieldException: Fields [kdf, kdfIterations] are required for type with serial name 'com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson', but they were missing at path: $ 12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.platform.datasource.network.serializer.BaseSurrogateSerializer.deserialize(BaseSurrogateSerializer.kt:41) 12-08 13:44:30.360 W/NetworkResultCall(29074): Caused by: kotlinx.serialization.MissingFieldException: Fields [kdf, kdfIterations] are required for type with serial name 'com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson', but they were missing 12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson.<init>(InternalPreLoginResponseJson.kt:11) 12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson.<init>(Unknown Source:0) 12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson$$serializer.deserialize(InternalPreLoginResponseJson.kt:11) 12-08 13:44:30.360 W/NetworkResultCall(29074): at com.x8bit.bitwarden.data.auth.datasource.network.model.InternalPreLoginResponseJson$$serializer.deserialize(InternalPreLoginResponseJson.kt:11) I can attach more if needed

kerem commented

Author

Owner

@BlackDex commented on GitHub (Dec 8, 2024):

@306bobby-android, looks like you are not using the latest version of Vaultwarden.

Those fields are returned always since forever.
And they changed to camelCase since v1.31.0.

@BlackDex commented on GitHub (Dec 8, 2024): @306bobby-android, looks like you are not using the latest version of Vaultwarden. Those fields are returned always since forever. And they changed to camelCase since v1.31.0.

kerem commented

Author

Owner

@306bobby-android commented on GitHub (Dec 8, 2024):

Interesting, then my docker is messing with me. Let me verify my version
number and get it updated and report back if I'm still encountering the
issue with a better log

On Sun, Dec 8, 2024, 2:08 PM Mathijs van Veluw @.***>
wrote:

@306bobby-android https://github.com/306bobby-android, looks like you
are not using the latest version of Vaultwarden.

Those fields are returned always since forever.
And they changed to camelCase since v1.31.0.

—
Reply to this email directly, view it on GitHub
https://github.com/dani-garcia/vaultwarden/issues/5237#issuecomment-2526333665,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCI56WC6AG6T4MRVMVXKLYD2ESKJVAVCNFSM6AAAAABSR446NKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWGMZTGNRWGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

@306bobby-android commented on GitHub (Dec 8, 2024): Interesting, then my docker is messing with me. Let me verify my version number and get it updated and report back if I'm still encountering the issue with a better log On Sun, Dec 8, 2024, 2:08 PM Mathijs van Veluw ***@***.***> wrote: > @306bobby-android <https://github.com/306bobby-android>, looks like you > are not using the latest version of Vaultwarden. > > Those fields are returned always since forever. > And they changed to camelCase since v1.31.0. > > — > Reply to this email directly, view it on GitHub > <https://github.com/dani-garcia/vaultwarden/issues/5237#issuecomment-2526333665>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BCI56WC6AG6T4MRVMVXKLYD2ESKJVAVCNFSM6AAAAABSR446NKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWGMZTGNRWGU> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

kerem commented

Author

Owner

@diagpope commented on GitHub (Dec 22, 2024):

The latest update from 2024.12.0 (19597) works on android for me.

@diagpope commented on GitHub (Dec 22, 2024): The latest update from 2024.12.0 (19597) works on android for me.

kerem commented

Author

Owner

@sairuk commented on GitHub (Dec 29, 2024):

same client 2024.12.0 (19597) with docker 1.32.7 worked for a brief period after reinstall (i.e. overnight) now no longer working, "last sync" under Settings->Other is blank, was populated with initial sync date after reinstall/setup

@sairuk commented on GitHub (Dec 29, 2024): same client 2024.12.0 (19597) with docker 1.32.7 worked for a brief period after reinstall (i.e. overnight) now no longer working, "last sync" under `Settings->Other` is blank, was populated with initial sync date after reinstall/setup

kerem commented

Author

Owner

@Cromoray commented on GitHub (Mar 24, 2025):

Any update on how to solve the problem?

@Cromoray commented on GitHub (Mar 24, 2025): Any update on how to solve the problem?

kerem commented