Fail Sync at create a SecureNote

[Crosus97]

Discussed in #4554

This discussion a bug and i think this must be reviewed (read the last discussion comment)

^{Originally posted by Crosus97 May 15, 2024}

Subject of the issue

when press de sync button apper a Fail Sync Error, that work until 3 o 4 days, no changes are made it

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.30.5
• Web-vault version: v2024.1.2b
• OS/Arch: linux/x86_64
• Running within a container: true (Base: Debian)
• Environment settings overridden: true
• Uses a reverse proxy: false (THIS IS TRUE BUT THE DIAGNOSTICS DIDNT DETECT IT, IS HAPROXY FROM PFSENSE)
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Browser/Server Time Check: true
• Server/NTP Time Check: true
• Domain Configuration Check: true
• HTTPS Check: true
• Database type: SQLite
• Database version: 3.44.0
• Clients used:
• Reverse proxy and version:
• Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden: ADMIN_TOKEN

{
  "_duo_akey": null,
  "_enable_duo": true,
  "_enable_email_2fa": false,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_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_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "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,
  "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,
  "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,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "Info",
  "log_timestamp_format": "%d-%m-%Y %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": 600000,
  "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": true,
  "signups_domains_whitelist": "",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": null,
  "smtp_password": null,
  "smtp_port": 587,
  "smtp_security": "starttls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": null,
  "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/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": false,
  "websocket_port": 3012,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Steps to reproduce

• create a secure note
• Press de sync button
  

I now detect than randomly sync, i think where the password must be sent on a field, the plugin automatically sync the database,

Expected behaviour

the plugin database must be synced

Actual behaviour

apper a sync error

Troubleshooting data

[BlackDex]

I'm not sure what you expect here. You mentioned it was solved and now open a ticket again.

Please elaborate what your reason is. Also, this is missing a lot of info which was discussed in that discussion.

[Crosus97]

im reporting a bug(?)
At least I think so...
Is it normal that if I create a secure note within vaultwarden, the synchronization stops working? Maybe it's my misunderstanding, and it's not a bug?

i create a Secure Note

then the sync stop working

i explain in the in the discussion.

[Crosus97]

Maybe it's not the place to report a bug and it's my fault.

[BlackDex]

Via which client, os, browser, phone etc.. please provide that kind of information

[tessus]

according to #3580 it seems that vw (or the client) sometimes stores (or sends):

"secureNote": {
        "type": null
      }

A solution was also suggested #3580 (reply in thread)

[BlackDex]

@tessus but it would be good to know which client, what fields are filled which are not etc.. else is hard to reproduce if at all. It also might be something in between for example. Nothing to do with either Vaultwarden or Bitwarden even.

[Crosus97]

in my case ocurred with android client and with the chrome plugin, the bitwarden windows app work fine

[BlackDex]

I used the android client just right now to add a secure note, and it sync's just fine afterwards.
Same goes for Chromium/Chrome, i can create a new secure note without any issues afterwards.

If you can reproduce this every time, then there must be something strange in between which causes the json to be changed?
Maybe the reverse proxy does something strange?

Can't be the database engine since that doesn't do anything special with json, and i use the same type.
I tested this both via nginx and haproxy, though for haproxy i just use tcp forwarding, not http, that might be able to do something with the input/output, but that would be weird too.

[Crosus97]

Timeline:
i maked this:

After 1 or 2 days I realized that my devices were not syncing.

Then I created the ticket, and it lasted as long as the ticket and the discussion lasted until the resolution date. As soon as I realized the problem, I deleted the secure note with the key, and it worked perfectly again

idk ¯_(ツ)_/¯

[BlackDex]

But, does it happen again if you create a new secure note?
Was it an older note which caused this?

[BlackDex]

It might be that some clients send wrong data, but in my memory that was only with very old clients and a buggy.
So, the current clients should just add correct data.
That makes me still wanting to know if this happens with the latest clients or not, since I'm not able to reproduce this without manually editing the database to start with. Not by using any client and adding a SecureNote.

Further could you check if there are more items like that.

SELECT * FROM ciphers WHERE atype=2 AND data LIKE '%"Type":null%';

If that returns one or more rows, then try to execute this query after making a backup of the database:

UPDATE ciphers
SET data = REPLACE(data, '"Type":null', '"Type":0')
WHERE data LIKE '%"Type":null%';

[tnorlin]

I had this very same issue. Sync stopped working for both Android and iPhone client, I got one hit with the above query and I looked into my Securenotes and had one item created at that exact created_at so I deleted that row (also from the Bin) - after that I could sync again.