Remove user from admin panel brake emergency contact. No error if domain is not allowed as emergency contact.

rizlas commented 1 month ago

Subject of the issue

Removing a user from the admin panel does not remove any relation from table emergency_access. This will brake emergency contact page and contacts won't be loaded.
Trying to add a contact with a domain that is not included in SIGNUPS_DOMAINS_WHITELIST is blocked (right behavior) but no message is shown to the user.

Deployment environment

vaultwarden version: 1.30.5

Install method: docker image
Clients used: web vault
Reverse proxy and version: nginx
MySQL/MariaDB or PostgreSQL version: postgres 16.3
Other relevant details:

Steps to reproduce

Problem 1:

user_a@fqdn.tld add user_b@fqdn.tld as his emergency contact
remove user_b@fqdn.tld from admin panel user section
user_a@fqdn.tld emergency contact page is now broken

Problem 2:

Add a contact whose domain is not in SIGNUPS_DOMAINS_WHITELIST and hit save

Expected behaviour

Problem 1:

user_a@fqdn.tld emergency contact page loaded and user_b@fqdn.tld not showing anymore

Problem 2:

A popup appears warning the user that the domain is not allowed or else.

Actual behaviour

Problem 1:

user_a@fqdn.tld emergency contact page not loading. Exception raised in logs.

Problem 2:

Save button is now an antistress. User doesn't know what's going on.

Troubleshooting data

Problem 1:

[2024-05-23 10:20:12.352][request][INFO] GET /api/emergency-access/trusted
[2024-05-23 10:20:12.353][panic][ERROR] thread 'rocket-worker-thread' panicked at 'Grantee user not found.': src/db/models/emergency_access.rs:88
   0: vaultwarden::init_logging::{{closure}}
   1: std::panicking::rust_panic_with_hook
   2: std::panicking::begin_panic_handler::{{closure}}
   3: std::sys_common::backtrace::__rust_end_short_backtrace
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::option::expect_failed
   7: vaultwarden::db::models::emergency_access::EmergencyAccess::to_json_grantee_details::{{closure}}
   8: vaultwarden::api::core::emergency_access::get_contacts::into_info::monomorphized_function::{{closure}}
   9: rocket::server::<impl rocket::rocket::Rocket<rocket::phase::Orbit>>::route::{{closure}}
  10: rocket::server::hyper_service_fn::{{closure}}::{{closure}}
  11: tokio::runtime::task::raw::poll
  12: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  13: tokio::runtime::scheduler::multi_thread::worker::run
  14: tokio::runtime::task::raw::poll
  15: std::sys_common::backtrace::__rust_begin_short_backtrace
  16: core::ops::function::FnOnce::call_once{{vtable.shim}}
  17: std::sys::pal::unix::thread::Thread::new::thread_start
  18: <unknown>
  19: clone

Problem 2:

Console error:

https://myvaultwarden/api/emergency-access/invite
[HTTP/2 400  372ms]

Object { response: {…}, message: "Email domain not eligible for invitations", validationErrors: {…}, captchaSiteKey: undefined, captchaRequired: false, statusCode: 400 }

stefan0xC commented 1 month ago

Problem 1 should have been fixed by #4337 which is available in the testing image.

Not sure if problem 2 is a problem we can fix. This should be handled client-side (in the web-vault).

BlackDex commented 1 month ago

Closing this as already fixed, and works as intended.

dani-garcia / vaultwarden