mirror of
https://github.com/hcengineering/platform.git
synced 2026-08-17 18:05:42 +02:00
* fix(account): authorize mergeSpecifiedPersons / canMergeSpecifiedPersons Both operations decoded the caller token and discarded the result, so any authenticated caller could merge any two persons by uuid. Merging re-points the secondary person's social ids onto the primary one, and neither login nor password recovery require a social id to be verified, so this reached as far as taking over an arbitrary account. Authorize both behind verifyMergePersonsAuthority: - global admin tokens and the tool/workspace services pass, matching the account level mergeSpecifiedAccounts; - everybody else must maintain the workspace their token carries, and both persons must be within its reach: a person holding an account elsewhere, and the platform wide system and guest accounts, are refused; - a login capable social id may not move onto an account the caller does not own. doMergePersons only refuses verified secondary social ids, which leaves the unverified ones a maintainer could mint for themselves. canMergeSpecifiedPersons answers false instead of throwing: it is the predicate the merge dialog polls, and it awaits it without a catch. Claude-Session: https://claude.ai/code/session_01ANdoXbdn5k2hZy734EwKe7 Signed-off-by: Don Kendall <dkendall@ledoweb.com> * test(account): cover merge persons authorization Nineteen cases over both operations: the reported attack shape, the maintainer to owner escalation through an unverified email, foreign accounts on either side of the merge, the platform guest account, and the paths that must keep working (workspace contacts, members, tool service and admin tokens). Removing the authorization check fails eight of them. Claude-Session: https://claude.ai/code/session_01ANdoXbdn5k2hZy734EwKe7 Signed-off-by: Don Kendall <dkendall@ledoweb.com> --------- Signed-off-by: Don Kendall <dkendall@ledoweb.com>