mirror of
https://github.com/sol1/rustguac.git
synced 2026-10-25 04:59:41 +00:00
Dave Kempe
44d17d7ca1
Moving an entry to another folder was done in the browser as "create a copy from the edit form, then delete the original". The page never receives an entry's secrets, so the copy had no password, private key, jump host credentials, Proxmox token or container password, and a $variable reference stored in the password field was lost the same way. The original was then deleted permanently. Clone had the same flaw. (#232) Two admin-only endpoints now do it from the stored entry: - POST .../entries/{entry}/move copies the full entry to the target and only then removes the original. If that removal fails it says the entry was copied, rather than reporting a plain failure. - POST .../entries/{entry}/copy copies it under a new name. Clone uses it and then applies the form's edits as an ordinary update, which keeps stored secrets it is not given. The target is written with Vault check-and-set (cas 0), so an existing entry is never overwritten, even by a concurrent writer. Scope, folder and names go through the existing Vault validation (only shared and instance scopes, no traversal, .config reserved, so a copy cannot replace a folder's access settings), and those failures are 400s. Both actions are audited, headline only. A note on the shared helper records that any future per-folder editing (#231) must require rights on both the source and the target folder.