starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-02-05 00:29:40 +03:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Manager unable to edit collections on testing branch #1413

New Issue
Closed
opened 2026-02-05 00:51:51 +03:00 by OVERLORD · 20 comments
OVERLORD commented 2026-02-05 00:51:51 +03:00
Owner
Copy Link

Originally created by @BlackDex on GitHub (Nov 23, 2022).

Originally assigned to: @BlackDex on GitHub.

Discussed in https://github.com/dani-garcia/vaultwarden/discussions/2930

Originally posted by louisfgr November 23, 2022
When trying to change or add new collections in the testing branch (v 1.26.0-7a767310) as a manager, the user is logged out and the following error appears in the log.

The issue seems to be similar to #2151 from Dec 2021

[2022-11-23 12:42:56.720][auth][ERROR] Unauthorized Error: You need to be Admin or Owner to call this endpoint
[2022-11-23 12:42:56.721][_][WARN] Request guard `AdminHeaders` failed: "You need to be Admin or Owner to call this endpoint".
[2022-11-23 12:42:56.722][_][WARN] No 401 catcher registered. Using Rocket default.

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.26.0-7a767310
  • Web-vault version: v2022.10.2
  • Running within Docker: true (Base: Debian)
  • Environment settings overridden: false
  • Uses a reverse proxy: true
  • IP Header check: true (X-Real-IP)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Database type: SQLite
  • Database version: 3.39.2
  • Clients used:
  • Reverse proxy and version:
  • Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden:

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": false,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_smtp_img_src": "cid:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "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_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 5 * * * *",
  "emergency_request_timeout_schedule": "0 5 * * * *",
  "enable_db_wal": true,
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": false,
  "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": "BitwardenTest",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": "/data/vaultwarden.log",
  "log_level": "warn",
  "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": "",
  "password_hints_allowed": true,
  "password_iterations": 100000,
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sends_allowed": false,
  "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": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "*************@********.***",
  "smtp_from_name": "BitwardenTest",
  "smtp_host": "***.***.**.**",
  "smtp_password": null,
  "smtp_port": 25,
  "smtp_security": "off",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": null,
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": 14,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": true,
  "websocket_port": 3012,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}
Originally created by @BlackDex on GitHub (Nov 23, 2022). Originally assigned to: @BlackDex on GitHub. ### Discussed in https://github.com/dani-garcia/vaultwarden/discussions/2930 <div type='discussions-op-text'> <sup>Originally posted by **louisfgr** November 23, 2022</sup> When trying to change or add new collections in the testing branch (v 1.26.0-7a767310) as a manager, the user is logged out and the following error appears in the log. The issue seems to be similar to #2151 from Dec 2021 ``` [2022-11-23 12:42:56.720][auth][ERROR] Unauthorized Error: You need to be Admin or Owner to call this endpoint [2022-11-23 12:42:56.721][_][WARN] Request guard `AdminHeaders` failed: "You need to be Admin or Owner to call this endpoint". [2022-11-23 12:42:56.722][_][WARN] No 401 catcher registered. Using Rocket default. ``` ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.26.0-7a767310 * Web-vault version: v2022.10.2 * Running within Docker: true (Base: Debian) * Environment settings overridden: false * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Database version: 3.39.2 * Clients used: * Reverse proxy and version: * Other relevant information: ### Config (Generated via diagnostics page) <details><summary>Show Running Config</summary> **Environment settings which are overridden:** ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": false, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_smtp_img_src": "cid:", "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_token": "***", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "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_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 5 * * * *", "emergency_request_timeout_schedule": "0 5 * * * *", "enable_db_wal": true, "extended_logging": true, "helo_name": null, "hibp_api_key": null, "icon_blacklist_non_global_ips": false, "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": "BitwardenTest", "invitations_allowed": true, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": "/data/vaultwarden.log", "log_level": "warn", "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": "", "password_hints_allowed": true, "password_iterations": 100000, "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sends_allowed": false, "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": null, "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "*************@********.***", "smtp_from_name": "BitwardenTest", "smtp_host": "***.***.**.**", "smtp_password": null, "smtp_port": 25, "smtp_security": "off", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": null, "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": 14, "trash_purge_schedule": "0 5 0 * * *", "use_syslog": false, "user_attachment_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "websocket_address": "0.0.0.0", "websocket_enabled": true, "websocket_port": 3012, "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details></div>
OVERLORD added the bug label 2026-02-05 00:51:51 +03:00
OVERLORD commented 2026-02-05 00:51:56 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (Nov 23, 2022):

Confirmed. Seems to be because of groups.

@BlackDex commented on GitHub (Nov 23, 2022): Confirmed. Seems to be because of groups.
OVERLORD commented 2026-02-05 00:51:58 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 23, 2022):

Trying to edit a collection will get the groups of a collection:
7a7673103f/src/api/core/organizations.rs (L1750-L1751)

Changing AdminHeaders to ManagerHeadersLoose fixes this issue but I noticed that Managers that are restricted to specific collections still get listed all collections (and will be logged out if trying to change a collection they are not given access to).

@stefan0xC commented on GitHub (Nov 23, 2022): Trying to edit a collection will get the groups of a collection: https://github.com/dani-garcia/vaultwarden/blob/7a7673103fb180098f18abe77b75ba085710b559/src/api/core/organizations.rs#L1750-L1751 Changing `AdminHeaders` to `ManagerHeadersLoose` fixes this issue but I noticed that Managers that are restricted to specific collections still get listed all collections (and will be logged out if trying to change a collection they are not given access to).
OVERLORD commented 2026-02-05 00:52:02 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (Nov 23, 2022):

I have no idea right now how this works on Bitwarden.
It might be needed to do some more filtering there, or ignore some stuff.

@BlackDex commented on GitHub (Nov 23, 2022): I have no idea right now how this works on Bitwarden. It might be needed to do some more filtering there, or ignore some stuff.
OVERLORD commented 2026-02-05 00:52:04 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 23, 2022):

Okay, after further testing this only affects the default collection. On non-default collections the options (gear symbol) are missing and clicking it I get a client-side warning that I am missing the required permissions:
client-side-error

So this might be a client-side issue.

@stefan0xC commented on GitHub (Nov 23, 2022): Okay, after further testing this only affects the default collection. On non-default collections the options (gear symbol) are missing and clicking it I get a client-side warning that I am missing the required permissions: ![client-side-error](https://user-images.githubusercontent.com/509385/203577781-76acdcf7-ae11-43a3-857a-5b17797bcf61.png) So this might be a client-side issue.
OVERLORD commented 2026-02-05 00:52:06 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 23, 2022):

this only affects the default collection

Okay, this only happened because the manager had no access to the collection but was part of a group that has access.

@stefan0xC commented on GitHub (Nov 23, 2022): > this only affects the default collection Okay, this only happened because the manager had no access to the collection but was part of a group that has access.
OVERLORD commented 2026-02-05 00:52:08 +03:00
Author
Owner
Copy Link

@louisfgr commented on GitHub (Nov 28, 2022):

Just tried the new testing version on my test system and again encountered similar problems.

Manager can now create collections and edit the users of this newly created collection, but when I try to edit the users of an already existing collection, I get this error again.

[2022-11-28 08:27:58.577][auth][ERROR] Unauthorized Error: The current user isn't a manager for this collection
[2022-11-28 08:27:58.577][_][WARN] Request guard `ManagerHeaders` failed: "The current user isn't a manager for this collection".
[2022-11-28 08:27:58.577][_][WARN] No 401 catcher registered. Using Rocket default.
@louisfgr commented on GitHub (Nov 28, 2022): Just tried the new testing version on my test system and again encountered similar problems. Manager can now create collections and edit the users of this newly created collection, but when I try to edit the users of an already existing collection, I get this error again. ``` [2022-11-28 08:27:58.577][auth][ERROR] Unauthorized Error: The current user isn't a manager for this collection [2022-11-28 08:27:58.577][_][WARN] Request guard `ManagerHeaders` failed: "The current user isn't a manager for this collection". [2022-11-28 08:27:58.577][_][WARN] No 401 catcher registered. Using Rocket default. ```
OVERLORD commented 2026-02-05 00:52:11 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 28, 2022):

Has the manager been given access to the collection or only via a group? If so, then this is the behaviour I have noticed which is a different bug and possible happens in Bitwarden as well (I can't test this because I don't have access to a business plan). Can you create a new issue?

@stefan0xC commented on GitHub (Nov 28, 2022): Has the manager been given access to the collection or only via a group? If so, then this is the behaviour I have noticed which is a different bug and possible happens in Bitwarden as well (I can't test this because I don't have access to a business plan). Can you create a new issue?
OVERLORD commented 2026-02-05 00:52:16 +03:00
Author
Owner
Copy Link

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

Please provide the layout/access of the manager you use, and which groups/collections you have configured so that we can try and reproduce this.

I am able to test this on a Bitwarden server.

@BlackDex commented on GitHub (Nov 28, 2022): Please provide the layout/access of the manager you use, and which groups/collections you have configured so that we can try and reproduce this. I am able to test this on a Bitwarden server.
OVERLORD commented 2026-02-05 00:52:22 +03:00
Author
Owner
Copy Link

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

I just re-opened this one, we just need more info.

@BlackDex commented on GitHub (Nov 28, 2022): I just re-opened this one, we just need more info.
OVERLORD commented 2026-02-05 00:52:25 +03:00
Author
Owner
Copy Link

@louisfgr commented on GitHub (Nov 28, 2022):

what @stefan0xC wrote seems to be the problem. The manager was only part of a group.

My broken configuration:

  • Manager without direct access to collections.
  • Group giving manager access to a collection (without any special permissions - no Hide Passwords; no Read Only)

The configuration starts working correctly as soon as I give the manager direct access to collections.
This is also the reason why my manager can edit the newly created collection, as the creating user automatically gets access.

Nevertheless, even if this is a Bitwarden issue, I think there should be a proper error message instead of logging out the user. (If that's possible. I am not a Rust developer, nor am I familiar with the Vaultwarden code).

@louisfgr commented on GitHub (Nov 28, 2022): what @stefan0xC wrote seems to be the problem. The manager was only part of a group. My broken configuration: - Manager without direct access to collections. - Group giving manager access to a collection (without any special permissions - no Hide Passwords; no Read Only) The configuration starts working correctly as soon as I give the manager direct access to collections. This is also the reason why my manager can edit the newly created collection, as the creating user automatically gets access. Nevertheless, even if this is a Bitwarden issue, I think there should be a proper error message instead of logging out the user. (If that's possible. I am not a Rust developer, nor am I familiar with the Vaultwarden code).
OVERLORD commented 2026-02-05 00:52:28 +03:00
Author
Owner
Copy Link

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

Thanks. I have tested this, and it is broken on Vaultwarden, and works fine on Bitwarden.
The issue here is that i think the allowed collections are not retrieved correctly, which in turn causes the user to be logged-out.
Which in turn is good if that user was tampering, but it shouldn't in this case.

Looking at this on how to solve this properly.

@BlackDex commented on GitHub (Nov 28, 2022): Thanks. I have tested this, and it is broken on Vaultwarden, and works fine on Bitwarden. The issue here is that i think the allowed collections are not retrieved correctly, which in turn causes the user to be logged-out. Which in turn is good if that user was tampering, but it shouldn't in this case. Looking at this on how to solve this properly.
OVERLORD commented 2026-02-05 00:52:30 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 28, 2022):

I think I found the problem. This function f3beaea9e9/src/db/models/collection.rs (L162-L205) is both called by ciphers f3beaea9e9/src/api/core/ciphers.rs (L116) and organizations f3beaea9e9/src/api/core/organizations.rs (L265) the latter of which should not include the collections via the groups table.

@stefan0xC commented on GitHub (Nov 28, 2022): I think I found the problem. This function https://github.com/dani-garcia/vaultwarden/blob/f3beaea9e95ff7fff679289916232c95621b517c/src/db/models/collection.rs#L162-L205 is both called by ciphers https://github.com/dani-garcia/vaultwarden/blob/f3beaea9e95ff7fff679289916232c95621b517c/src/api/core/ciphers.rs#L116 and organizations https://github.com/dani-garcia/vaultwarden/blob/f3beaea9e95ff7fff679289916232c95621b517c/src/api/core/organizations.rs#L265 the latter of which should **not** include the collections via the groups table.
OVERLORD commented 2026-02-05 00:52:32 +03:00
Author
Owner
Copy Link

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

I actually think it does need to do that. How else would someone be able by group rights to access a collection?

The problem lays in the ManagerHeaders, which calls a query which does not take groups into account.

@BlackDex commented on GitHub (Nov 28, 2022): I actually think it does need to do that. How else would someone be able by group rights to access a collection? The problem lays in the ManagerHeaders, which calls a query which does not take groups into account.
OVERLORD commented 2026-02-05 00:52:33 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 28, 2022):

How else would someone be able by group rights to access a collection?

Not sure why we would need that? The question would be if Bitwarden returns all collections in the /api/collections call or only the ones you are able to manage? (As far as I tested it and what I gathered from the output I can gather it's the latter.)

The access to the collection I get via group rights is given through the call in ciphers (and does not depend on the /api/collections result) which I think means that it should return a different result (i.e. more) than the /api/collections call which tells the web-vault which collections I can change. That these are returning the same is the cause of the bug as far as I can tell.

I'm not sure if it's better to write a new function for the cipher call or the organization call but probably something like this is needed:

diff --git a/src/api/core/ciphers.rs b/src/api/core/ciphers.rs
index 39635ef..6da7de5 100644
--- a/src/api/core/ciphers.rs
+++ b/src/api/core/ciphers.rs
@@ -113,7 +113,7 @@ async fn sync(data: SyncData, headers: Headers, mut conn: DbConn) -> Json<Value>
     }

     let mut collections_json = Vec::new();
-    for c in Collection::find_by_user_uuid(headers.user.uuid.clone(), &mut conn).await {
+    for c in Collection::find_by_user_uuid_for_sync(headers.user.uuid.clone(), &mut conn).await {
         collections_json.push(c.to_json_details(&headers.user.uuid, Some(&cipher_sync_data), &mut conn).await);
     }

diff --git a/src/db/models/collection.rs b/src/db/models/collection.rs
index c4507e1..0306880 100644
--- a/src/db/models/collection.rs
+++ b/src/db/models/collection.rs
@@ -158,8 +158,35 @@ impl Collection {
                 .from_db()
         }}
     }
-
     pub async fn find_by_user_uuid(user_uuid: String, conn: &mut DbConn) -> Vec<Self> {
+        db_run! { conn: {
+            collections::table
+            .left_join(users_collections::table.on(
+                users_collections::collection_uuid.eq(collections::uuid).and(
+                    users_collections::user_uuid.eq(user_uuid.clone())
+                )
+            ))
+            .left_join(users_organizations::table.on(
+                collections::org_uuid.eq(users_organizations::org_uuid).and(
+                    users_organizations::user_uuid.eq(user_uuid.clone())
+                )
+            ))
+            .filter(
+                users_organizations::status.eq(UserOrgStatus::Confirmed as i32)
+            )
+            .filter(
+                users_collections::user_uuid.eq(user_uuid).or( // Directly accessed collection
+                    users_organizations::access_all.eq(true) // access_all in Organization
+                )
+            )
+            .select(collections::all_columns)
+            .distinct()
+            .load::<CollectionDb>(conn).expect("Error loading collections").from_db()
+        }}
+    }
+
+
+    pub async fn find_by_user_uuid_for_sync(user_uuid: String, conn: &mut DbConn) -> Vec<Self> {
         db_run! { conn: {
             collections::table
             .left_join(users_collections::table.on(
@stefan0xC commented on GitHub (Nov 28, 2022): > How else would someone be able by group rights to access a collection? > Not sure why we would need that? The question would be if Bitwarden returns all collections in the `/api/collections` call or only the ones you are able to manage? (As far as I tested it and what I gathered from the output I can gather it's the latter.) The access to the collection I get via group rights is given through the call in ciphers (and does not depend on the `/api/collections` result) which I think means that it should return a different result (i.e. more) than the /api/collections call which tells the web-vault which collections I can change. That these are returning the same is the cause of the bug as far as I can tell. I'm not sure if it's better to write a new function for the cipher call or the organization call but probably something like this is needed: ```rust diff --git a/src/api/core/ciphers.rs b/src/api/core/ciphers.rs index 39635ef..6da7de5 100644 --- a/src/api/core/ciphers.rs +++ b/src/api/core/ciphers.rs @@ -113,7 +113,7 @@ async fn sync(data: SyncData, headers: Headers, mut conn: DbConn) -> Json<Value> } let mut collections_json = Vec::new(); - for c in Collection::find_by_user_uuid(headers.user.uuid.clone(), &mut conn).await { + for c in Collection::find_by_user_uuid_for_sync(headers.user.uuid.clone(), &mut conn).await { collections_json.push(c.to_json_details(&headers.user.uuid, Some(&cipher_sync_data), &mut conn).await); } diff --git a/src/db/models/collection.rs b/src/db/models/collection.rs index c4507e1..0306880 100644 --- a/src/db/models/collection.rs +++ b/src/db/models/collection.rs @@ -158,8 +158,35 @@ impl Collection { .from_db() }} } - pub async fn find_by_user_uuid(user_uuid: String, conn: &mut DbConn) -> Vec<Self> { + db_run! { conn: { + collections::table + .left_join(users_collections::table.on( + users_collections::collection_uuid.eq(collections::uuid).and( + users_collections::user_uuid.eq(user_uuid.clone()) + ) + )) + .left_join(users_organizations::table.on( + collections::org_uuid.eq(users_organizations::org_uuid).and( + users_organizations::user_uuid.eq(user_uuid.clone()) + ) + )) + .filter( + users_organizations::status.eq(UserOrgStatus::Confirmed as i32) + ) + .filter( + users_collections::user_uuid.eq(user_uuid).or( // Directly accessed collection + users_organizations::access_all.eq(true) // access_all in Organization + ) + ) + .select(collections::all_columns) + .distinct() + .load::<CollectionDb>(conn).expect("Error loading collections").from_db() + }} + } + + + pub async fn find_by_user_uuid_for_sync(user_uuid: String, conn: &mut DbConn) -> Vec<Self> { db_run! { conn: { collections::table .left_join(users_collections::table.on( ```
OVERLORD commented 2026-02-05 00:52:38 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 28, 2022):

Note: I only made this patch to test if this would fix the issue which it does. I have not had time to test this for other possible side effects or come up with a better name. Maybe there is also a cleaner way to express this than code duplication, which is why I did not make a pull request yet.

@stefan0xC commented on GitHub (Nov 28, 2022): Note: I only made this patch to test if this would fix the issue which it does. I have not had time to test this for other possible side effects or come up with a better name. Maybe there is also a cleaner way to express this than code duplication, which is why I did not make a pull request yet.
OVERLORD commented 2026-02-05 00:52:42 +03:00
Author
Owner
Copy Link

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

Bitwarden returns all the collections the manager has access to, including those granted by groeps.

@BlackDex commented on GitHub (Nov 28, 2022): Bitwarden returns all the collections the manager has access to, including those granted by groeps.
OVERLORD commented 2026-02-05 00:52:45 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 28, 2022):

Okay, one difference I just noticed is that we return a list of collection for both /api/collections and /api/organization/<org_uuid>/collections while Bitwarden returns a list of collectionDetails for the former, which also has the fields readOnly and hidePassword. (Not sure if this is relevant.)

Regarding:

The problem lays in the ManagerHeaders, which calls a query which does not take groups into account.

Do you mean that a Manager that has access to a collection via a group should be able to edit that collection?

@stefan0xC commented on GitHub (Nov 28, 2022): Okay, one difference I just noticed is that we return a list of `collection` for both /api/collections and /api/organization/<org_uuid>/collections while Bitwarden returns a list of `collectionDetails` for the former, which also has the fields readOnly and hidePassword. (Not sure if this is relevant.) Regarding: > The problem lays in the ManagerHeaders, which calls a query which does not take groups into account. Do you mean that a Manager that has access to a collection via a group should be able to edit that collection?
OVERLORD commented 2026-02-05 00:52:49 +03:00
Author
Owner
Copy Link

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

Okay, one difference I just noticed is that we return a list of collection for both /api/collections and /api/organization/<org_uuid>/collections while Bitwarden returns a list of collectionDetails for the former, which also has the fields readOnly and hidePassword. (Not sure if this is relevant.)

Regarding:

The problem lays in the ManagerHeaders, which calls a query which does not take groups into account.

Do you mean that a Manager that has access to a collection via a group should be able to edit that collection?

Yes, since only admins or owners are able to manage those rights and managers (i think) are able to manage all rights they have access too.

@BlackDex commented on GitHub (Nov 28, 2022): > Okay, one difference I just noticed is that we return a list of `collection` for both /api/collections and /api/organization/<org_uuid>/collections while Bitwarden returns a list of `collectionDetails` for the former, which also has the fields readOnly and hidePassword. (Not sure if this is relevant.) > > Regarding: > > > The problem lays in the ManagerHeaders, which calls a query which does not take groups into account. > > Do you mean that a Manager that has access to a collection via a group should be able to edit that collection? Yes, since only admins or owners are able to manage those rights and managers (i think) are able to manage all rights they have access too.
OVERLORD commented 2026-02-05 00:52:52 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub (Nov 29, 2022):

Ah, sorry. I thought the problem was that they should not have transitive access but I thought about it and it does make sense if you have a larger organization with many collections where you want to utilize a group for management instead of adding an individual manager to each collection.

@stefan0xC commented on GitHub (Nov 29, 2022): Ah, sorry. I thought the problem was that they should not have transitive access but I thought about it and it does make sense if you have a larger organization with many collections where you want to utilize a group for management instead of adding an individual manager to each collection.
OVERLORD commented 2026-02-05 00:52:53 +03:00
Author
Owner
Copy Link

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

I see that the new web-vault (v2022.11.1) reports a warning if a manager does not have access.
Though for our item, it still needs fixing, since that still logs-out the user.

Because of this, i think we do need to thoroughly check all those queries and flows.

@BlackDex commented on GitHub (Nov 29, 2022): I see that the new web-vault (v2022.11.1) reports a warning if a manager does not have access. Though for our item, it still needs fixing, since that still logs-out the user. Because of this, i think we do need to thoroughly check all those queries and flows.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
troubleshooting
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1413
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?