Originally created by @siwica on GitHub (May 29, 2019).
After changing some user-rights for an organization back and forth, said user is suddenly displayed as being part of no organization (even after reinstating the original permissions). Even after re-inviting the user to the organization + confirmation an email with subject Invitation to confirmed is sent but the web-interface still shows no organization for the user.
Server logs upon login show an error for said user foo@bar.de that does not occur for other users:
[2019-05-29 12:53:12][rocket::rocket][INFO] POST /api/accounts/prelogin application/json; charset=utf-8:
[2019-05-29 12:53:12][_][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2019-05-29 12:53:12][_][INFO] Outcome: Success
[2019-05-29 12:53:12][_][INFO] Response succeeded.
[2019-05-29 12:53:12][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded; charset=utf-8:
[2019-05-29 12:53:12][_][INFO] Matched: POST /identity/connect/token (login)
[2019-05-29 12:53:12][bitwarden_rs::api::identity][INFO] User foo@bar.de logged in successfully. IP: 10.255.0.2
[2019-05-29 12:53:12][_][INFO] Outcome: Success
[2019-05-29 12:53:12][_][INFO] Response succeeded.
[2019-05-29 12:53:12][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-05-29 12:53:12][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-05-29 12:53:12][_][INFO] Outcome: Success
[2019-05-29 12:53:12][_][INFO] Response succeeded.
[2019-05-29 12:53:12][rocket::rocket][INFO] GET /api/sync?excludeDomains=true application/json:
[2019-05-29 12:53:12][_][INFO] Matched: GET /api/sync?<data..> (sync)
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:999:5
[2019-05-29 12:53:16][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-05-29 12:53:16][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-05-29 12:53:16][_][INFO] Outcome: Success
[2019-05-29 12:53:16][_][INFO] Response succeeded.
[2019-05-29 12:53:39][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-05-29 12:53:39][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-05-29 12:53:39][_][INFO] Outcome: Success
[2019-05-29 12:53:39][_][INFO] Response succeeded.
[2019-05-29 12:53:45][rocket::rocket][INFO] GET /api/organizations/<hash>/users application/json:
[2019-05-29 12:53:45][_][INFO] Matched: GET /api/organizations/<org_id>/users (get_org_users)
[2019-05-29 12:53:45][_][INFO] Outcome: Success
[2019-05-29 12:53:45][_][INFO] Response succeeded.
[2019-05-29 12:53:47][rocket::rocket][INFO] GET /api/organizations/<hash>/collections application/json:
[2019-05-29 12:53:47][_][INFO] Matched: GET /api/organizations/<org_id>/collections (get_org_collections)
[2019-05-29 12:53:47][_][INFO] Outcome: Success
[2019-05-29 12:53:47][_][INFO] Response succeeded.
[2019-05-29 12:53:47][rocket::rocket][INFO] GET /api/organizations/<hash>/users/<user-hash> application/json:
[2019-05-29 12:53:47][_][INFO] Matched: GET /api/organizations/<org_id>/users/<org_user_id> (get_user)
[2019-05-29 12:53:47][_][INFO] Outcome: Success
[2019-05-29 12:53:47][_][INFO] Response succeeded.
Originally created by @siwica on GitHub (May 29, 2019).
After changing some user-rights for an organization back and forth, said user is suddenly displayed as being part of _no_ organization (even after reinstating the original permissions). Even after re-inviting the user to the organization + confirmation an email with subject _Invitation to <organisation> confirmed_ is sent but the web-interface still shows no organization for the user.
Server logs upon login show an error for said user _foo@bar.de_ that does not occur for other users:
```
[2019-05-29 12:53:12][rocket::rocket][INFO] POST /api/accounts/prelogin application/json; charset=utf-8:
[2019-05-29 12:53:12][_][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2019-05-29 12:53:12][_][INFO] Outcome: Success
[2019-05-29 12:53:12][_][INFO] Response succeeded.
[2019-05-29 12:53:12][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded; charset=utf-8:
[2019-05-29 12:53:12][_][INFO] Matched: POST /identity/connect/token (login)
[2019-05-29 12:53:12][bitwarden_rs::api::identity][INFO] User foo@bar.de logged in successfully. IP: 10.255.0.2
[2019-05-29 12:53:12][_][INFO] Outcome: Success
[2019-05-29 12:53:12][_][INFO] Response succeeded.
[2019-05-29 12:53:12][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-05-29 12:53:12][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-05-29 12:53:12][_][INFO] Outcome: Success
[2019-05-29 12:53:12][_][INFO] Response succeeded.
[2019-05-29 12:53:12][rocket::rocket][INFO] GET /api/sync?excludeDomains=true application/json:
[2019-05-29 12:53:12][_][INFO] Matched: GET /api/sync?<data..> (sync)
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:999:5
[2019-05-29 12:53:16][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-05-29 12:53:16][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-05-29 12:53:16][_][INFO] Outcome: Success
[2019-05-29 12:53:16][_][INFO] Response succeeded.
[2019-05-29 12:53:39][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-05-29 12:53:39][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-05-29 12:53:39][_][INFO] Outcome: Success
[2019-05-29 12:53:39][_][INFO] Response succeeded.
[2019-05-29 12:53:45][rocket::rocket][INFO] GET /api/organizations/<hash>/users application/json:
[2019-05-29 12:53:45][_][INFO] Matched: GET /api/organizations/<org_id>/users (get_org_users)
[2019-05-29 12:53:45][_][INFO] Outcome: Success
[2019-05-29 12:53:45][_][INFO] Response succeeded.
[2019-05-29 12:53:47][rocket::rocket][INFO] GET /api/organizations/<hash>/collections application/json:
[2019-05-29 12:53:47][_][INFO] Matched: GET /api/organizations/<org_id>/collections (get_org_collections)
[2019-05-29 12:53:47][_][INFO] Outcome: Success
[2019-05-29 12:53:47][_][INFO] Response succeeded.
[2019-05-29 12:53:47][rocket::rocket][INFO] GET /api/organizations/<hash>/users/<user-hash> application/json:
[2019-05-29 12:53:47][_][INFO] Matched: GET /api/organizations/<org_id>/users/<org_user_id> (get_user)
[2019-05-29 12:53:47][_][INFO] Outcome: Success
[2019-05-29 12:53:47][_][INFO] Response succeeded.
```
Hmm not sure where that could come from, I can't see any unwraps in the sync endpoint. Are you using the docker image? Which version (You can check the log right after the server starts)?
Can you set the env variable RUST_BACKTRACE=1, relaunch the server and try to reproduce the error again? Hope that gives a better message.
@dani-garcia commented on GitHub (May 29, 2019):
Hmm not sure where that could come from, I can't see any unwraps in the sync endpoint. Are you using the docker image? Which version (You can check the log right after the server starts)?
Can you set the env variable `RUST_BACKTRACE=1`, relaunch the server and try to reproduce the error again? Hope that gives a better message.
Maybe this is stupid question, but did you confirm (as org admin) the user in the organization after the user is invited?
@mprasil commented on GitHub (May 31, 2019):
Maybe this is stupid question, but did you confirm (as org admin) the user in the organization after the user is invited?
@mprasil Yes, the user was confirmed and I was perfectly able to use the organizations collection up until it was no longer displayed.
@dani-garcia I messaged the person in charge of our installation and will get back to you as soon as I have the requested information.
@siwica commented on GitHub (May 31, 2019):
@mprasil Yes, the user was confirmed and I was perfectly able to use the organizations collection up until it was no longer displayed.
@dani-garcia I messaged the person in charge of our installation and will get back to you as soon as I have the requested information.
I got the same strange behaviour. It happend after I tried to add an existing user a second time.
Dropping the user from the organisation doesn't worked.
I'am using the docker version (build my own Swarm config, instead of the default) with Sqlite DB. After adding RUST_BACKTRACE=1 I always get the following after login of the faulty user:
[2019-06-14 15:54:59][rocket::rocket][INFO] POST /api/accounts/prelogin application/json; charset=utf-8:
[2019-06-14 15:54:59][_][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2019-06-14 15:54:59][_][INFO] Outcome: Success
[2019-06-14 15:54:59][_][INFO] Response succeeded.
[2019-06-14 15:55:00][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded; charset=utf-8:
[2019-06-14 15:55:00][_][INFO] Matched: POST /identity/connect/token (login)
[2019-06-14 15:55:00][bitwarden_rs::api::identity][INFO] User faulty-user@gmx.de logged in successfully. IP: 78.232.251.70
[2019-06-14 15:55:00][_][INFO] Outcome: Success
[2019-06-14 15:55:00][_][INFO] Response succeeded.
[2019-06-14 15:55:00][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-06-14 15:55:00][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-06-14 15:55:00][_][INFO] Outcome: Success
[2019-06-14 15:55:00][_][INFO] Response succeeded.
[2019-06-14 15:55:00][rocket::rocket][INFO] GET /api/sync?excludeDomains=true application/json:
[2019-06-14 15:55:00][_][INFO] Matched: GET /api/sync?<data..> (sync)
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:999:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at ./cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/libunwind.rs:97
1: backtrace::backtrace::trace_unsynchronized
at ./cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:47
3: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:36
4: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:197
5: std::panicking::default_hook
at src/libstd/panicking.rs:211
6: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:474
7: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:381
8: rust_begin_unwind
at src/libstd/panicking.rs:308
9: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
10: core::result::unwrap_failed
11: bitwarden_rs::db::models::cipher::Cipher::to_json
12: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
13: bitwarden_rs::api::core::ciphers::rocket_route_fn_sync
14: <F as rocket::handler::Handler>::handle
15: rocket::rocket::Rocket::route_and_process
16: <rocket::rocket::Rocket as hyper::server::Handler>::handle
17: hyper::server::Worker<H>::handle_connection
18: hyper::server::listener::spawn_with::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[2019-06-14 15:55:00][ws::io][INFO] Accepted a new tcp connection from 10.0.0.87:46744.
[2019-06-14 15:55:00][bitwarden_rs::api::notifications][INFO] Server got message '{"protocol":"messagepack","version":1}'.
RUST_BACKTRACE=full shows:
[2019-06-14 16:00:47][_][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2019-06-14 16:00:47][_][INFO] Outcome: Success
[2019-06-14 16:00:47][_][INFO] Response succeeded.
[2019-06-14 16:00:47][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded; charset=utf-8:
[2019-06-14 16:00:47][_][INFO] Matched: POST /identity/connect/token (login)
[2019-06-14 16:00:48][bitwarden_rs::api::identity][INFO] User fauly-user@gmx.de logged in successfully. IP: 78.232.251.70
[2019-06-14 16:00:48][_][INFO] Outcome: Success
[2019-06-14 16:00:48][_][INFO] Response succeeded.
[2019-06-14 16:00:49][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-06-14 16:00:49][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-06-14 16:00:49][_][INFO] Outcome: Success
[2019-06-14 16:00:49][_][INFO] Response succeeded.
[2019-06-14 16:00:49][rocket::rocket][INFO] GET /api/sync?excludeDomains=true application/json:
[2019-06-14 16:00:49][_][INFO] Matched: GET /api/sync?<data..> (sync)
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:999:5
stack backtrace:
0: 0x564cc8a925da - backtrace::backtrace::libunwind::trace::h95cf0d6f90455f99
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/libunwind.rs:97
1: 0x564cc8a925da - backtrace::backtrace::trace_unsynchronized::hf1bc4b307d386ce0
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/mod.rs:66
2: 0x564cc8a925da - std::sys_common::backtrace::_print::h17c85b34b8085bc3
at src/libstd/sys_common/backtrace.rs:47
3: 0x564cc8a925da - std::sys_common::backtrace::print::hcd95718fa811f3ee
at src/libstd/sys_common/backtrace.rs:36
4: 0x564cc8a925da - std::panicking::default_hook::{{closure}}::h9a777852f3c432bb
at src/libstd/panicking.rs:197
5: 0x564cc8a922db - std::panicking::default_hook::h20a55232f8970617
at src/libstd/panicking.rs:211
6: 0x564cc8a92d4f - std::panicking::rust_panic_with_hook::h5522dfdebc12d6f5
at src/libstd/panicking.rs:474
7: 0x564cc8a928d1 - std::panicking::continue_panic_fmt::h2e20e3cd1b619a34
at src/libstd/panicking.rs:381
8: 0x564cc8a927b5 - rust_begin_unwind
at src/libstd/panicking.rs:308
9: 0x564cc8ab4fec - core::panicking::panic_fmt::he1d95cf9fc209195
at src/libcore/panicking.rs:85
10: 0x564cc81d3872 - core::result::unwrap_failed::h33d457743009f6a1
11: 0x564cc83a01dd - bitwarden_rs::db::models::cipher::Cipher::to_json::ha5715ebbccecb376
12: 0x564cc81df7c5 - <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold::h02e954ea61b5c4fd
13: 0x564cc83a3b29 - bitwarden_rs::api::core::ciphers::rocket_route_fn_sync::hcc1e4f0f11c0e932
14: 0x564cc895a52d - <F as rocket::handler::Handler>::handle::hf93c73aebefd461e
15: 0x564cc8949af1 - rocket::rocket::Rocket::route_and_process::h04d15153fb4d9316
16: 0x564cc89472ad - <rocket::rocket::Rocket as hyper::server::Handler>::handle::hde54a1d98b9f8291
17: 0x564cc8960c38 - hyper::server::Worker<H>::handle_connection::h9c5a90d41f33399b
18: 0x564cc8928e0b - hyper::server::listener::spawn_with::{{closure}}::h5cf617a9f7114e52
19: 0x564cc8924f46 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5eee62f38e0ee356
20: 0x564cc8968106 - std::panicking::try::do_call::h026d6a970ae175e7
21: 0x564cc8a9cb79 - __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:85
22: 0x564cc892651d - core::ops::function::FnOnce::call_once{{vtable.shim}}::h87a319ddb5fc03c3
23: 0x564cc8a81fee - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hf976226e6c27a77d
at /rustc/7840a0b753a065a41999f1fb6028f67d33e3fdd5/src/liballoc/boxed.rs:746
24: 0x564cc8a9bf0f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h98647ef726ff7a66
at /rustc/7840a0b753a065a41999f1fb6028f67d33e3fdd5/src/liballoc/boxed.rs:746
25: 0x564cc8a9bf0f - std::sys_common::thread::start_thread::hf603385dcffbe09c
at src/libstd/sys_common/thread.rs:13
26: 0x564cc8a9bf0f - std::sys::unix::thread::Thread::new::thread_start::hc9ec3f28206cd778
at src/libstd/sys/unix/thread.rs:79
27: 0x7f4d1352d4a3 - start_thread
28: 0x7f4d13058d0e - __clone
29: 0x0 - <unknown>
[2019-06-14 16:00:49][ws::io][INFO] Accepted a new tcp connection from 10.0.0.87:45988.
[2019-06-14 16:00:49][bitwarden_rs::api::notifications][INFO] Server got message '{"protocol":"messagepack","version":1}'.
@kaotika commented on GitHub (Jun 14, 2019):
I got the same strange behaviour. It happend after I tried to add an existing user a second time.
Dropping the user from the organisation doesn't worked.
I'am using the docker version (build my own Swarm config, instead of the default) with Sqlite DB. After adding `RUST_BACKTRACE=1` I always get the following after login of the faulty user:
```
[2019-06-14 15:54:59][rocket::rocket][INFO] POST /api/accounts/prelogin application/json; charset=utf-8:
[2019-06-14 15:54:59][_][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2019-06-14 15:54:59][_][INFO] Outcome: Success
[2019-06-14 15:54:59][_][INFO] Response succeeded.
[2019-06-14 15:55:00][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded; charset=utf-8:
[2019-06-14 15:55:00][_][INFO] Matched: POST /identity/connect/token (login)
[2019-06-14 15:55:00][bitwarden_rs::api::identity][INFO] User faulty-user@gmx.de logged in successfully. IP: 78.232.251.70
[2019-06-14 15:55:00][_][INFO] Outcome: Success
[2019-06-14 15:55:00][_][INFO] Response succeeded.
[2019-06-14 15:55:00][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-06-14 15:55:00][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-06-14 15:55:00][_][INFO] Outcome: Success
[2019-06-14 15:55:00][_][INFO] Response succeeded.
[2019-06-14 15:55:00][rocket::rocket][INFO] GET /api/sync?excludeDomains=true application/json:
[2019-06-14 15:55:00][_][INFO] Matched: GET /api/sync?<data..> (sync)
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:999:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at ./cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/libunwind.rs:97
1: backtrace::backtrace::trace_unsynchronized
at ./cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:47
3: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:36
4: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:197
5: std::panicking::default_hook
at src/libstd/panicking.rs:211
6: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:474
7: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:381
8: rust_begin_unwind
at src/libstd/panicking.rs:308
9: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
10: core::result::unwrap_failed
11: bitwarden_rs::db::models::cipher::Cipher::to_json
12: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
13: bitwarden_rs::api::core::ciphers::rocket_route_fn_sync
14: <F as rocket::handler::Handler>::handle
15: rocket::rocket::Rocket::route_and_process
16: <rocket::rocket::Rocket as hyper::server::Handler>::handle
17: hyper::server::Worker<H>::handle_connection
18: hyper::server::listener::spawn_with::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[2019-06-14 15:55:00][ws::io][INFO] Accepted a new tcp connection from 10.0.0.87:46744.
[2019-06-14 15:55:00][bitwarden_rs::api::notifications][INFO] Server got message '{"protocol":"messagepack","version":1}'.
```
`RUST_BACKTRACE=full` shows:
```
[2019-06-14 16:00:47][_][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2019-06-14 16:00:47][_][INFO] Outcome: Success
[2019-06-14 16:00:47][_][INFO] Response succeeded.
[2019-06-14 16:00:47][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded; charset=utf-8:
[2019-06-14 16:00:47][_][INFO] Matched: POST /identity/connect/token (login)
[2019-06-14 16:00:48][bitwarden_rs::api::identity][INFO] User fauly-user@gmx.de logged in successfully. IP: 78.232.251.70
[2019-06-14 16:00:48][_][INFO] Outcome: Success
[2019-06-14 16:00:48][_][INFO] Response succeeded.
[2019-06-14 16:00:49][rocket::rocket][INFO] POST /notifications/hub/negotiate text/plain; charset=UTF-8:
[2019-06-14 16:00:49][_][INFO] Matched: POST /notifications/hub/negotiate (negotiate)
[2019-06-14 16:00:49][_][INFO] Outcome: Success
[2019-06-14 16:00:49][_][INFO] Response succeeded.
[2019-06-14 16:00:49][rocket::rocket][INFO] GET /api/sync?excludeDomains=true application/json:
[2019-06-14 16:00:49][_][INFO] Matched: GET /api/sync?<data..> (sync)
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:999:5
stack backtrace:
0: 0x564cc8a925da - backtrace::backtrace::libunwind::trace::h95cf0d6f90455f99
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/libunwind.rs:97
1: 0x564cc8a925da - backtrace::backtrace::trace_unsynchronized::hf1bc4b307d386ce0
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/mod.rs:66
2: 0x564cc8a925da - std::sys_common::backtrace::_print::h17c85b34b8085bc3
at src/libstd/sys_common/backtrace.rs:47
3: 0x564cc8a925da - std::sys_common::backtrace::print::hcd95718fa811f3ee
at src/libstd/sys_common/backtrace.rs:36
4: 0x564cc8a925da - std::panicking::default_hook::{{closure}}::h9a777852f3c432bb
at src/libstd/panicking.rs:197
5: 0x564cc8a922db - std::panicking::default_hook::h20a55232f8970617
at src/libstd/panicking.rs:211
6: 0x564cc8a92d4f - std::panicking::rust_panic_with_hook::h5522dfdebc12d6f5
at src/libstd/panicking.rs:474
7: 0x564cc8a928d1 - std::panicking::continue_panic_fmt::h2e20e3cd1b619a34
at src/libstd/panicking.rs:381
8: 0x564cc8a927b5 - rust_begin_unwind
at src/libstd/panicking.rs:308
9: 0x564cc8ab4fec - core::panicking::panic_fmt::he1d95cf9fc209195
at src/libcore/panicking.rs:85
10: 0x564cc81d3872 - core::result::unwrap_failed::h33d457743009f6a1
11: 0x564cc83a01dd - bitwarden_rs::db::models::cipher::Cipher::to_json::ha5715ebbccecb376
12: 0x564cc81df7c5 - <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold::h02e954ea61b5c4fd
13: 0x564cc83a3b29 - bitwarden_rs::api::core::ciphers::rocket_route_fn_sync::hcc1e4f0f11c0e932
14: 0x564cc895a52d - <F as rocket::handler::Handler>::handle::hf93c73aebefd461e
15: 0x564cc8949af1 - rocket::rocket::Rocket::route_and_process::h04d15153fb4d9316
16: 0x564cc89472ad - <rocket::rocket::Rocket as hyper::server::Handler>::handle::hde54a1d98b9f8291
17: 0x564cc8960c38 - hyper::server::Worker<H>::handle_connection::h9c5a90d41f33399b
18: 0x564cc8928e0b - hyper::server::listener::spawn_with::{{closure}}::h5cf617a9f7114e52
19: 0x564cc8924f46 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5eee62f38e0ee356
20: 0x564cc8968106 - std::panicking::try::do_call::h026d6a970ae175e7
21: 0x564cc8a9cb79 - __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:85
22: 0x564cc892651d - core::ops::function::FnOnce::call_once{{vtable.shim}}::h87a319ddb5fc03c3
23: 0x564cc8a81fee - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hf976226e6c27a77d
at /rustc/7840a0b753a065a41999f1fb6028f67d33e3fdd5/src/liballoc/boxed.rs:746
24: 0x564cc8a9bf0f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h98647ef726ff7a66
at /rustc/7840a0b753a065a41999f1fb6028f67d33e3fdd5/src/liballoc/boxed.rs:746
25: 0x564cc8a9bf0f - std::sys_common::thread::start_thread::hf603385dcffbe09c
at src/libstd/sys_common/thread.rs:13
26: 0x564cc8a9bf0f - std::sys::unix::thread::Thread::new::thread_start::hc9ec3f28206cd778
at src/libstd/sys/unix/thread.rs:79
27: 0x7f4d1352d4a3 - start_thread
28: 0x7f4d13058d0e - __clone
29: 0x0 - <unknown>
[2019-06-14 16:00:49][ws::io][INFO] Accepted a new tcp connection from 10.0.0.87:45988.
[2019-06-14 16:00:49][bitwarden_rs::api::notifications][INFO] Server got message '{"protocol":"messagepack","version":1}'.
```
I pushed a change to remove the unwraps that were failing, though I'm not sure why they were failing in the first place to be honest. Specially because the stack trace points to the Cipher to JSON conversion, not sure how that is related to users and organizations.
The changes are in 76f38621de, the images will be built after some hours. I'd appreciate some testing to see if the issue is fixed.
@dani-garcia commented on GitHub (Jun 14, 2019):
I pushed a change to remove the unwraps that were failing, though I'm not sure why they were failing in the first place to be honest. Specially because the stack trace points to the Cipher to JSON conversion, not sure how that is related to users and organizations.
The changes are in 76f38621de23c2f6f2b42df5d05d73c8128c6ee5, the images will be built after some hours. I'd appreciate some testing to see if the issue is fixed.
@dani-garcia many thanks for the quick fix. The problem is gone now and I could add the user to the organisation. And the user doesn't get's kicked out from the organization when I tried to reinvite him, what caused to problem in the first place.
The only strange thing are a few nonsense entries (attached image). Don't know if this is related to the problem. There where no error messages in the logs about that. They just can't be edited.
@kaotika commented on GitHub (Jun 15, 2019):
@dani-garcia many thanks for the quick fix. The problem is gone now and I could add the user to the organisation. And the user doesn't get's kicked out from the organization when I tried to reinvite him, what caused to problem in the first place.
The only strange thing are a few nonsense entries (attached image). Don't know if this is related to the problem. There where no error messages in the logs about that. They just can't be edited.

Well the reason for the panic before was because the cipher data couldn't be decoded, so I simply made it so in that case it would just return an empty value. So it makes sense that you get empty values I guess.
Now I'd want to know what's causing those errors in the first place, are those empty ciphers new or are they existing ones that have had their data corrupted somehow?
It's also strange that they can't be edited either, can you delete them at least?
@dani-garcia commented on GitHub (Jun 15, 2019):
Well the reason for the panic before was because the cipher data couldn't be decoded, so I simply made it so in that case it would just return an empty value. So it makes sense that you get empty values I guess.
Now I'd want to know what's causing those errors in the first place, are those empty ciphers new or are they existing ones that have had their data corrupted somehow?
It's also strange that they can't be edited either, can you delete them at least?
Yes, I can delete them. Attaching files also worked.
As far as I can tell these are new entries and no other entries are corrupted.
Sharing isn't possible and fails with (don't know if this helps anyway):
[2019-06-16 20:05:24][rocket::rocket][INFO] PUT /api/ciphers/2314bbd9-7865-44ff-bf2e-e8ae4ba4bc7c/share application/json; charset=utf-8:
[2019-06-16 20:05:24][_][INFO] Matched: PUT /api/ciphers/<uuid>/share (put_cipher_share)
[2019-06-16 20:05:24][_][ERROR] Couldn't parse JSON body: Error("invalid type: null, expected a string", line: 1, column: 781)
[2019-06-16 20:05:24][_][INFO] Outcome: Failure
[2019-06-16 20:05:24][_][WARN] Responding with 422 Unprocessable Entity catcher.
@kaotika commented on GitHub (Jun 16, 2019):
Yes, I can delete them. Attaching files also worked.
As far as I can tell these are new entries and no other entries are corrupted.
Sharing isn't possible and fails with (don't know if this helps anyway):
```
[2019-06-16 20:05:24][rocket::rocket][INFO] PUT /api/ciphers/2314bbd9-7865-44ff-bf2e-e8ae4ba4bc7c/share application/json; charset=utf-8:
[2019-06-16 20:05:24][_][INFO] Matched: PUT /api/ciphers/<uuid>/share (put_cipher_share)
[2019-06-16 20:05:24][_][ERROR] Couldn't parse JSON body: Error("invalid type: null, expected a string", line: 1, column: 781)
[2019-06-16 20:05:24][_][INFO] Outcome: Failure
[2019-06-16 20:05:24][_][WARN] Responding with 422 Unprocessable Entity catcher.
```
This is quite old issue with no response. Going to close this now, feel free to reopen if you need more help.
@mprasil commented on GitHub (Nov 27, 2019):
This is quite old issue with no response. Going to close this now, feel free to reopen if you need more help.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @siwica on GitHub (May 29, 2019).
After changing some user-rights for an organization back and forth, said user is suddenly displayed as being part of no organization (even after reinstating the original permissions). Even after re-inviting the user to the organization + confirmation an email with subject Invitation to confirmed is sent but the web-interface still shows no organization for the user.
Server logs upon login show an error for said user foo@bar.de that does not occur for other users:
@dani-garcia commented on GitHub (May 29, 2019):
Hmm not sure where that could come from, I can't see any unwraps in the sync endpoint. Are you using the docker image? Which version (You can check the log right after the server starts)?
Can you set the env variable
RUST_BACKTRACE=1, relaunch the server and try to reproduce the error again? Hope that gives a better message.@mprasil commented on GitHub (May 31, 2019):
Maybe this is stupid question, but did you confirm (as org admin) the user in the organization after the user is invited?
@siwica commented on GitHub (May 31, 2019):
@mprasil Yes, the user was confirmed and I was perfectly able to use the organizations collection up until it was no longer displayed.
@dani-garcia I messaged the person in charge of our installation and will get back to you as soon as I have the requested information.
@kaotika commented on GitHub (Jun 14, 2019):
I got the same strange behaviour. It happend after I tried to add an existing user a second time.
Dropping the user from the organisation doesn't worked.
I'am using the docker version (build my own Swarm config, instead of the default) with Sqlite DB. After adding
RUST_BACKTRACE=1I always get the following after login of the faulty user:RUST_BACKTRACE=fullshows:@dani-garcia commented on GitHub (Jun 14, 2019):
I pushed a change to remove the unwraps that were failing, though I'm not sure why they were failing in the first place to be honest. Specially because the stack trace points to the Cipher to JSON conversion, not sure how that is related to users and organizations.
The changes are in
76f38621de, the images will be built after some hours. I'd appreciate some testing to see if the issue is fixed.@kaotika commented on GitHub (Jun 15, 2019):
@dani-garcia many thanks for the quick fix. The problem is gone now and I could add the user to the organisation. And the user doesn't get's kicked out from the organization when I tried to reinvite him, what caused to problem in the first place.
The only strange thing are a few nonsense entries (attached image). Don't know if this is related to the problem. There where no error messages in the logs about that. They just can't be edited.
@dani-garcia commented on GitHub (Jun 15, 2019):
Well the reason for the panic before was because the cipher data couldn't be decoded, so I simply made it so in that case it would just return an empty value. So it makes sense that you get empty values I guess.
Now I'd want to know what's causing those errors in the first place, are those empty ciphers new or are they existing ones that have had their data corrupted somehow?
It's also strange that they can't be edited either, can you delete them at least?
@kaotika commented on GitHub (Jun 16, 2019):
Yes, I can delete them. Attaching files also worked.
As far as I can tell these are new entries and no other entries are corrupted.
Sharing isn't possible and fails with (don't know if this helps anyway):
@mprasil commented on GitHub (Nov 11, 2019):
Is this still a problem? If it is, have you tried the latest version of
bitwarden_rs?@mprasil commented on GitHub (Nov 27, 2019):
This is quite old issue with no response. Going to close this now, feel free to reopen if you need more help.