Filtering of synchronized secrets on collection, organization, and/or folder (#12)
* Filtering feature, minor logic changes +: Add IP validation (to properly log IP even when trusted proxy is missing) +: Added synchronization of decrypted organization, collection, and folder names (for filtering purposes) +: Changed sync behavior to prevent collapsing multiple logins with the same name +: Added possibility to filter logins based on organization, collection, and folder name/id in GetSecret +: Added support for space character in secret name validation (it is also properly URL-decoded) * Update README * Fixes related to issues reported by CodeRabbit: +: Changed british use of organisations in README +: Reduced line count in parseSecretFilters by including helper function for filter dimensions resolution +: Added comment clarifying absence of existence checking on dimension IDs as opposed to names +: Removed efensive comma split logic on IPs (redundant due to IPValidation setting on Fiber) +: Changed Query validator to align with name validator (mainly removing hard-coded values) +: Added comments to decryptVaultLabel for clarity +: Change empty SyncNameMaps instance with emptySyncNameMaps helper for consistency +: Add lexical sort for lookupIDByName for deterministic result in case of multiple matches * Bumped logging to warn and added entity metadata in log * Unit tests: +: Added unit tests for every newly introduced or changed function +: Rewrote NewClient constructor to accept optional preloaded data (so it can be used in test scenarios) * Changes requested by CodeRabbit
This commit is contained in:
1 parent
cac042a5c4
commit
76b82d4dba
11 files changed
+1174
-88
No files matched your search
@@ -305,6 +305,20 @@ When you request `/secret/DATABASE_URL`, the API:
|
||||
|
||||
This means you can name your Vaultwarden items naturally (e.g., "Database URL") and fetch them with any casing.
|
||||
|
||||
**Colliding names**: By default, the first match will be selected and returned. To help distinguish between matches with the same name, you can split them up into different organizations, collections, or folders to your liking.
|
||||
You can then use either the ID or the name of these groupings as a filter for the request.
|
||||
Examples:
|
||||
- `GET /secret/DATABASE_URL?organization_name=Organization1`
|
||||
- `GET /secret/DATABASE_URL?organization_id=<organization_uuid>`
|
||||
- `GET /secret/DATABASE_URL?collection_name=Project1`
|
||||
- `GET /secret/DATABASE_URL?collection_id=<collection_uuid>`
|
||||
- `GET /secret/DATABASE_URL?folder_name=Deployments`
|
||||
- `GET /secret/DATABASE_URL?folder_id=<folder_uuid>`
|
||||
|
||||
You can combine the filters for even more fine-grained filtering, as such:
|
||||
- `GET /secret/DATABASE_URL?organization_name=Organization1&collection_name=Project1`
|
||||
However, for each dimension (organization | collection | folder) you can only filter on one value. Additionally, specifying the name and the ID are mutually exclusive; you cannot specify both at the same time.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Error | Cause | Fix |
|
||||
|
||||
Reference in new issue
Block a user