search

dani-garcia / vaultwarden

Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs
GNU Affero General Public License v3.0
39.46k stars 1.91k forks source link

iOS App - an error has occurred #5069

Closed theo-rettisch closed 1 month ago

theo-rettisch commented 1 month ago

Vaultwarden Support String

Your environment (Generated via diagnostics page)

Config (Generated via diagnostics page)

Show Running Config **Environment settings which are overridden:** ADMIN_TOKEN ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_max_note_size": 10000, "_smtp_img_src": "cid:", "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_session_lifetime": 20, "admin_token": "***", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "auth_request_purge_schedule": "30 * * * * *", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "***************", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://**********************", "domain_origin": "*****://**********************", "domain_path": "", "domain_set": true, "duo_context_purge_schedule": "30 * * * * *", "duo_host": null, "duo_ikey": null, "duo_skey": null, "duo_use_iframe": false, "email_2fa_auto_fallback": false, "email_2fa_enforce_on_verified_invite": false, "email_attempts_limit": 3, "email_change_allowed": true, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 3 * * * *", "emergency_request_timeout_schedule": "0 7 * * * *", "enable_db_wal": true, "enable_websocket": true, "enforce_single_org_with_reset_pw_policy": false, "event_cleanup_schedule": "0 10 0 * * *", "events_days_retain": null, "experimental_client_feature_flags": "fido2-vault-credentials", "extended_logging": true, "helo_name": null, "hibp_api_key": null, "http_request_block_non_global_ips": true, "http_request_block_regex": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "increase_note_size_limit": false, "invitation_expiration_hours": 120, "invitation_org_name": "Vaultwarden", "invitations_allowed": false, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "", "org_events_enabled": false, "org_groups_enabled": false, "password_hints_allowed": true, "password_iterations": 100000, "push_enabled": false, "push_identity_uri": "https://identity.bitwarden.com", "push_installation_id": "***", "push_installation_key": "***", "push_relay_uri": "https://push.bitwarden.com", "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sendmail_command": null, "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": false, "signups_domains_whitelist": "", "signups_verify": true, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": "Login", "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "**********************", "smtp_from_name": "Vaultwarden", "smtp_host": "*************", "smtp_password": "***", "smtp_port": 587, "smtp_security": "starttls", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": "**********************", "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": null, "trash_purge_schedule": "0 5 0 * * *", "use_sendmail": false, "use_syslog": false, "user_attachment_limit": null, "user_send_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ```

Vaultwarden Build Version

v1.32.1

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

traefik:v2.9

Host/Server Operating System

Linux

Operating System Version

Ubuntu 22.04.5 LTS

Clients

iOS

Client Version

2024.9.2 (1106)

Steps To Reproduce

  1. Install the app from the App Store
  2. Change to self hosted server
  3. Enter email and password
  4. Perform 2FA (WebAuthn)

Expected Result

Entries are successfully synchronized

Actual Result

The error message “An error has occurred” appears

Logs

vault  | [2024-10-10 13:35:58.256][start][INFO] Rocket has launched from http://0.0.0.0:80
vault  | [2024-10-10 13:39:28.527][request][INFO] GET /api/config
vault  | [2024-10-10 13:39:28.528][response][INFO] (config) GET /api/config => 200 OK
vault  | [2024-10-10 13:39:28.528][request][INFO] GET /api/config
vault  | [2024-10-10 13:39:28.529][response][INFO] (config) GET /api/config => 200 OK
vault  | [2024-10-10 13:39:34.825][request][INFO] GET /api/devices/knowndevice
vault  | [2024-10-10 13:39:34.827][response][INFO] (get_known_device) GET /api/devices/knowndevice => 200 OK
vault  | [2024-10-10 13:39:51.383][request][INFO] POST /identity/accounts/prelogin
vault  | [2024-10-10 13:39:51.385][response][INFO] (prelogin) POST /identity/accounts/prelogin => 200 OK
vault  | [2024-10-10 13:39:51.482][request][INFO] POST /identity/connect/token
vault  | [2024-10-10 13:39:51.555][error][ERROR] 2FA token not provided
vault  | [2024-10-10 13:39:51.555][response][INFO] (login) POST /identity/connect/token => 400 Bad Request
vault  | [2024-10-10 13:39:59.213][request][INFO] POST /identity/connect/token
vault  | [2024-10-10 13:39:59.553][vaultwarden::api::identity][INFO] User username@example.tld logged in successfully. IP: xxx.xxx.xxx.xxx
vault  | [2024-10-10 13:39:59.553][response][INFO] (login) POST /identity/connect/token => 200 OK
vault  | [2024-10-10 13:39:59.673][request][INFO] GET /api/config
vault  | [2024-10-10 13:39:59.673][response][INFO] (config) GET /api/config => 200 OK
vault  | [2024-10-10 13:39:59.872][request][INFO] GET /api/sync
vault  | [2024-10-10 13:39:59.896][response][INFO] (sync) GET /api/sync?<data..> => 200 OK
vault  | [2024-10-10 13:40:00.498][request][INFO] GET /api/sync
vault  | [2024-10-10 13:40:00.533][response][INFO] (sync) GET /api/sync?<data..> => 200 OK

Screenshots or Videos

(message says: An error occured) screenshot-of-error-message

Additional Context

I have tried the following, but nothing has helped

BlackDex commented 1 month ago

several other reports regarding this already. But as of yet, nobody provided any useful details to tackle this. There are also reports of this at Bitwarden , though, unclear to me if those are only with Vaultwarden self-hosted or also Bitwarden.

https://github.com/bitwarden/ios/issues/1025 https://github.com/bitwarden/ios/issues/891

Until someone is able to figure out what specific item is causing this, it is going to be very very difficult to track this down. All other clients seem to work just fine, including the Native Android.

bricej13 commented 1 month ago

I was able to solve the problem by updating my Vaultwarden to the latest (1.32.1)

BlackDex commented 1 month ago

But the TS is already on v1.32.1

BlackDex commented 1 month ago

Also, i tested several account's i have, and no issue on the iOS device i have using the exact same client version 2024.9.2 (1106)

And i know several users on my system have an iOS device, and they all have a working app.

cplaetzinger commented 1 month ago

I've the same issue. Any idea which information could be helpful to debug this issue?

When I try to login via the iOs app the server only logs the following

bitwarden_1  | [2024-10-10 19:22:23.189][request][INFO] POST /identity/accounts/prelogin
bitwarden_1  | [2024-10-10 19:22:23.195][response][INFO] (prelogin) POST /identity/accounts/prelogin => 200 OK
BlackDex commented 1 month ago

I've the same issue. Any idea which information could be helpful to debug this issue?

When I try to login via the iOs app the server only logs the following

bitwarden_1  | [2024-10-10 19:22:23.189][request][INFO] POST /identity/accounts/prelogin
bitwarden_1  | [2024-10-10 19:22:23.195][response][INFO] (prelogin) POST /identity/accounts/prelogin => 200 OK

Are you using Vaultwarden 1.32.1?

cplaetzinger commented 1 month ago

I've the same issue. Any idea which information could be helpful to debug this issue? When I try to login via the iOs app the server only logs the following

bitwarden_1  | [2024-10-10 19:22:23.189][request][INFO] POST /identity/accounts/prelogin
bitwarden_1  | [2024-10-10 19:22:23.195][response][INFO] (prelogin) POST /identity/accounts/prelogin => 200 OK

Are you using Vaultwarden 1.32.1?

I thought that I'm on 1.32.1 but it seems that docker-compose pull did not pull the latest version. After configuring 1.32.1 explicitly it worked. Thanks!

W1BTR commented 1 month ago

I have the same issue, we use yunohost, and I cant update it yet as it requires a yunohost version that hasnt been released yet. Guess it's time to move to docker for it, lol

Gerardv514 commented 1 month ago

According to this comment, could it be some emoji in a vault item jacking it up?

Philambdo commented 1 month ago

I am using vaultwarden on nixos with the latest available version 1.32.1:

From the Diagnostic Page:

Server Latest
    1.32.1 
Web Installed
    2024.6.2 
Web Latest
    2024.6.2c

Recently i upgraded my iphone to ios 18 and now i get the same issue.

Additionally i have sometimes the problem that i can't save within the firefox plugin or the dedicated app. (I'm not sure if this is related or some other websocket issue?)

Saving in the Web-App is working fine.

I tried a little bit of ngrep between haproxy and the vaultwarden, but all i got is the following response with return code 200:

date: Fri, 11 Oct 2024 08:41:31 GMT.
.
{"Kdf":0,"KdfIterations":600000,"KdfMemory":null,"KdfParallelism":null}
######
BlackDex commented 1 month ago

@Philambdo Websocket connections have nothing to do with saving an item (unless you modified it on client 1, and then try to modify it via client 2 which still has the old data).

It might be an iOS18 issue then? Are there users here which still are on iOS17 or lower? Because the phone i have for testing is an older model and is stuck on iOS 15 even.

Philambdo commented 1 month ago

It might not be the iOS Version after all (or at least not alone). I Just fetched the ipad with iOS 17.7 and Bitwarden App 2024.09.02 and its showing the same error message. I also used other accounts on my instance to rule out a broken password - with no success. I am not sure how to debug any further.

If there is any information i can provide just give me a heads up.

Philambdo commented 1 month ago

Another thing. Just to be sure. The version that should work with current Bitwarden App is 1.32.1 and not latest?

Because nixos is using the following Checkout from Git: https://hydra.nixos.org/build/274609331#tabs-buildinputs

BlackDex commented 1 month ago

1.32.1 and latest should be the same regarding the container images. I do not know where and how nixos downloads the source of this project. So i can't answer that question.

Gerardv514 commented 1 month ago

I’m on iOS 18 running BW app 2024.9.2 and latest Vaultwarden and I am not seeing an issue. I also have an organization setup with two users and a few test accounts.

Its got to be an item in the vault

theo-rettisch commented 1 month ago

According to this comment, could it be some emoji in a vault item jacking it up?

I have no entries with emojis.

I checked if my app version (2024.9.2 (1106)) works with a the SaaS version - it does.

Could attached files be the problem?

BlackDex commented 1 month ago

Files are probably not an issue. Those are only references to files, nothing more.

My best guess would be the new key per cipher stuff. But I'm also not able to trigger any issue when i have entries with that.

To troubleshoot it you should create a backup first, let nobody else access the server anymore and then delete each cipher one-by-one from the vault and trash, and check if you can sync again with the mobile client.

theo-rettisch commented 1 month ago

Files are probably not an issue. Those are only references to files, nothing more.

My best guess would be the new key per cipher stuff. But I'm also not able to trigger any issue when i have entries with that.

To troubleshoot it you should create a backup first, let nobody else access the server anymore and then delete each cipher one-by-one from the vault and trash, and check if you can sync again with the mobile client.

Hm... yeah. I will try it tomorrow. I am curious what the problem is.

Doomsdayrs commented 1 month ago

This is not limited to IOS, Experienced this on Android today too.

Gerardv514 commented 1 month ago

This is not limited to IOS, Experienced this on Android today too.

Can you share anything informative?

BlackDex commented 1 month ago

@Doomsdayrs and you are 101% sure you are running the latest 1.32.1 version of Vaultwarden?

BlackDex commented 1 month ago

@theo-rettisch , that would be great. Any information might be useful.

Doomsdayrs commented 1 month ago

@Doomsdayrs and you are 101% sure you are running the latest 1.32.1 version of Vaultwarden?

Just double checked, and for some reason my pod didn't update

I thought it was, but it seems it wasn't.

2024.6.2 makes it work for me

Gerardv514 commented 1 month ago

@Doomsdayrs and you are 101% sure you are running the latest 1.32.1 version of Vaultwarden?

Just double checked, and for some reason my pod didn't update

I thought it was, but it seems it wasn't.

2024.6.2 makes it work for me

🙄

theo-rettisch commented 1 month ago

I found the solution - at least for me. After I deleted every entry from the trash, the iOS client was able to synchronize successfully.

edit: i will try to find out which of the entries caused the problem

theo-rettisch commented 1 month ago

Ok. I had an entry in my trash with custom fields but for these fields the field type (hidden / password, text, boolean) were missing. Both of them were text fields. image

After i deleted the faulty fields the iOS client synchronized successfully.

Unfortunately I don't know which version I updated from but it was definitely < 1.31

BlackDex commented 1 month ago

@theo-rettisch Do you have the original entry from the database? That would be supper!!

theo-rettisch commented 1 month ago

@BlackDex Here you go. 

SELECT * FROM ciphers WHERE uuid = "uuid";
{
    "uuid": "uuid",
    "created_at": "2023-06-02 12:05:35.996569427",
    "updated_at": "2024-10-12 09:06:46.699149120",
    "user_uuid": "user_uuid",
    "organization_uuid": null,
    "atype": 2,
    "name": "snowflake",
    "notes": null,
    "fields": "[{\"Name\":\"data field 1 name\",\"Type\":\"0\",\"data field 1 value\":\"Value\"},{\"Name\":\"data field 2 name\",\"Type\":\"0\",\"Value\":\"data field 2 value\"}]",
    "data": "{\"Type\":0}",
    "password_history": null,
    "deleted_at": null,
    "reprompt": 0,
    "key": null
}

(i couldn't resist to replace the encrypted data with text...)

miberecz commented 1 month ago

I had the same issue. Solved with updating both the iOS app and the container running VW App version 2024.9.2 VW version 1.32.1

Philambdo commented 1 month ago

Hello all,

so as i had no further way of debugging and no idea how to proceed i did a vanilla install on a different vm via podman with the lastest version, with an empty database and all. => Login works

So i tried to copy over the database stuff to the container => Login works

So it boils down to nixos having an issue. I removed everything from the server and did a "fresh" install (which is nixos doing during an upgrade all the time anyway) and guess what: => Login works

So now i have no clue what part of the old install wasn't correctly updated or misconfigured by me ( i had still some websocket config left in the environment file pointing to port 3012 which was replaced by rocket in 1.31 i guess).

I'm sorry for the troubles but at least another thumbs up for version 1.32.1 in combination with ios 18 and latest bitwarden app from me.

Keep up the good work.

mleisi commented 1 month ago

I encountered the same error using Bitwarden mobile client 2024.9.2 (1106) on iOS 17.6.1 against vaultwarden 1.30.5 running in a docker container on a Synology.

Web access and Bitwarden desktop client 2024.6.3 (25879) on MacOS 14.5 were not affected.

Upgrading to vaultwarden 1.32.1 fixed the issue with the Bitwarden mobile client.

Gerardv514 commented 1 month ago

I encountered the same error using Bitwarden mobile client 2024.9.2 (1106) on iOS 17.6.1 against vaultwarden 1.30.5 running in a docker container on a Synology.

Web access and Bitwarden desktop client 2024.6.3 (25879) on MacOS 14.5 were not affected.

Upgrading to vaultwarden 1.32.1 fixed the issue with the Bitwarden mobile client.

This is a different issue than here that yes was fixed. It looks like there maybe still one more instance out here causing issues, and this is known because they have updated to 1.32.1 and still have an issue. So for anyone having the same issue but on an old version, that then upgraded, and is now resolved that is NOT the same issue as what some are still reporting. As mentioned the last bit of what some are reporting are already on 1.32.1 and are having the issue.

Anyone further saying that have the same issue, needs to be already on 1.32.1 and if not you need to update first because your specific issue may already be handled and handled in other threads.

This thread is for anyone already on 1.32.1 and experiencing an issue.

BlackDex commented 1 month ago

@theo-rettisch, it looks like the item you posted is not the same item you which was in your trash i think. As it has no deleted_at date. So it probably is either the result of after you updated it, or not the same item.

I need to know how it looked like when it was causing issues, before you fixed it.

theo-rettisch commented 1 month ago

@BlackDex, it seems it does not matter if it is deleted or not. After i restored the entry the client could still not synchronize. I removed the two faulty custom fields and then it worked.

Here's the same entry in deleted-state:

{
    "uuid": "uuid",
    "created_at": "2023-06-02 12:05:35.996569427",
    "updated_at": "2023-06-02 12:42:43.627804640",
    "user_uuid": "user_uuid",
    "organization_uuid": null,
    "atype": 2,
    "name": "snowflake",
    "notes": null,
    "fields": "[{\"Name\":\"data field 1 name\",\"Type\":\"0\",\"Value\":\"data field 1 value\"},{\"Name\":\"data field 2 name\",\"Type\":\"0\",\"Value\":\"data field 2 value\"}]",
    "data": "{\"Type\":0}",
    "password_history": null,
    "deleted_at": "2023-06-02 12:42:43.627699313",
    "reprompt": 0,
    "key": null
}
BlackDex commented 1 month ago

Thanks @theo-rettisch, after an other good look, i think i have found the issue. The Type values are strings, while all other clients work fine with this, the iOS does not.

theo-rettisch commented 1 month ago

The specific item were created by the api. I will validate tomorrow some more entries in another installation which were created by the api too. Maybe this is the problem.

BlackDex commented 1 month ago

Well, i think we should do some more type casting/converting on what is incoming. This does mean we need to do more processing during the input of ciphers or other API calls especially since the new clients they are more strict regarding the types of those fields.

BlackDex commented 1 month ago

Ok, the just built testing tagged container images should work now with the faulty items. And this should hopefully resolve all issues with iOS sync.

theo-rettisch commented 1 month ago

Yeah, this works! Thank you!

StefanGruell commented 1 month ago

Hi, i am running the testing tagged container but i am still running into this error.

Which information do you need? grafik

I switched from my iPhone 8 to an iPhone 16 Pro. Both have the version 2924.9.2. While on the old phone it still works the new one shows me the error.

Any help is kindly appreciated!

BlackDex commented 1 month ago

First, i think you probably mend to say v2024.9.2 else you are living in a very far future, and then I'm glad to see Vaultwarden and Bitwarden still exits 🤣

Maybe what the exact error is the client is showing. If there are any logs in Vaultwarden or your reverse proxy during these attempts.

Be sure to validate the domain you configured in the client, one small typo is made very quickly. Also, check if you are able to access your web-vault via the Safari Browser and if there are no SSL/Certificate issues reported just to be sure.

StefanGruell commented 1 month ago

Haha ye ofc i meant v2024.9.2 😄

So the error in the client i am getting is grafik

It is a selfhosted without any outside connection. I can connect via the browser and log in. The server logs can be seen here when trying to connect. grafik

BlackDex commented 1 month ago

Looks like a TLS/SSL Issue to me. Either you have not configured Vaultwarden correctly for the used certificate which i think is probably the issue, since you seem to try connect via a local IP address. And i doubt you have a certificate created for that specific IP address. If you are using a self-signed certificate, it should then still have that specific IP in it's Subject Alt Names. But this is totally out of scope of this specific issue.

Either do not use SSL if only running via local IP's and see if that solves it, if so, then fix a proper SSL Certificate with a domain linked to it. Or it might be an issue that Rocket somehow is not able to correctly communicate with the new iOS18, which i doubt, but could be of course. In that case, try to add a well known reverse proxy in-front of Vaultwarden and see if that solves your issues.

Also, i have no clue on how to allow/add/trust self-signed certificates on an iOS device, so i would suggest to search for that somewhere else.

StefanGruell commented 1 month ago

Well after some investigation i think i found the issue. Yes I use a self-signed certificate with that exact IP but everything is as far as I can see set up correctly.

I found out that in the iOS 18 settings i am not able to trust my own certificate even though its installed. As seen in that or that post i am sadly not the only one.

I guess i gotta wait for an iOS update to fix it.

Still thanks for the help!

BlackDex commented 1 month ago

@StefanGruell looking at https://support.apple.com/en-us/102390 I'm not sure which cert you installed, but i think you need both the CA Cert and Vaultwarden Cert to be installed/trusted.

Looking a bit more, it seems a lot if users have this, and the Apple fora's are also filled with issues.

StefanGruell commented 1 month ago

@BlackDex If understand correctly (I did it on my old iPhone and it did work) I have to install the CA Cert, then trust it and after that trust the Vaultwarden Cert.

Yeah I think Apple did a bit of an oopsie there.

shelterx commented 3 weeks ago

Fyi, I had this error or a few weeks, I updated vaultwarden to latest version. Did not help. Only thing that helped was to start over, removing the vaultwarden docker, make a backup of the vault in json format and removing the data folder.

BlackDex commented 3 weeks ago

And you probably do not have a backup maybe? So that we could try and compare solve this without the need of exporting and starting all over again?

shelterx commented 3 weeks ago

Not sure where to look, I dumped the databases and ran a diff on them, the only noticeable change was that the new one contained these changes:

+CREATE TABLE twofactor_duo_ctx (
+    state      TEXT    NOT NULL,
+    user_email TEXT    NOT NULL,
+    nonce      TEXT    NOT NULL,
+    exp        INTEGER NOT NULL,
+
+    PRIMARY KEY (state)
+);

-  ip_address  TEXT     NOT NULL,
+  ip_address  TEXT     NOT NULL, device_type INTEGER NOT NULL DEFAULT 14,
BlackDex commented 3 weeks ago

That tells me that you previous update didn't succeeded fully, and you were probably not running the latest version of Vaultwarden when you deleted everything.

My guess would be the container was still running an older version of Vaultwarden which is known to have issues with iOS clients. And the latest version of Vaultwarden works, which has those changes in the database, and are totally unrelated btw.