fix: [users] Add get_user_me() and fix stale get_user(0) doc

[elhoim]

BLUF — Add get_user_me() for the current user and delete the false claim that get_user(0) does it.

• Problem — MISP's UsersController::view() special-cases only the literal string "me"; users/view/0 is not special-cased and throws NotFoundException, yet get_user()'s doc comment advertised it as the current-user shortcut.
• Fix — Added MispClient::get_user_me() to both client.rs and client_blocking.rs, requesting users/view/me as PyMISP's get_user(user='me') default does, and removed the false line from the doc comment.
• Effect — Callers have a working way to fetch the authenticated user instead of following documentation into a 404.
• CI — Red for repo-level reasons unrelated to this PR: the job ran on ubuntu-22.04 (no php8.3 mod_php) and test_event_crud_lifecycle raced the publish worker; both fixed in PR fix: [ci] Run integration tests on ubuntu-24.04 to match php8.3 #53.

Finding

doc says get_user(0) for current user but MISP special-cases the string "me"
users/view/0 throws NotFoundException; with an i64 parameter the real shortcut is unreachable.

Change

Confirmed the finding: MISP's UsersController::view() special-cases only the literal string "me" ($id = $this->Auth->user('id') when "me" === $id); users/view/0 is not special-cased and falls through to User->find(), throwing NotFoundException. The get_user() doc comment claiming get_user(0) reaches the current-user shortcut was false. Added MispClient::get_user_me() (async client.rs and blocking client_blocking.rs) that requests users/view/me directly, matching PyMISP's get_user(user='me') default, and removed the false claim from get_user()'s doc comment. Existing get_user_parses_wrapped test (asserts users/view/1) was already correct MISP truth and was left unchanged; added a new test for the new method.

Upstream evidence

MISP core app/Controller/UsersController.php:46-50 (public function view($id = null) { if ("me" === $id) { $id = $this->Auth->user('id'); } ... }); PyMISP pymisp/api.py:2575-2583 (def get_user(self, user: ... = 'me', ...): user_id = get_uuid_or_id_from_abstract_misp(user); r = self._prepare_request('GET', f'users/view/{user_id}'))

Verified against MISP core 843b6744 and PyMISP e7debb4f.

Tests

• get_user_me_hits_literal_me_path (src/client.rs) - new wiremock test asserting GET users/view/me; fails before the fix via compile error since get_user_me() did not exist, passes after. The pre-existing get_user_parses_wrapped test asserts users/view/1 which is already correct MISP behavior and was left unchanged, not rewritten.

Note on the original finding

Accurate as written. Verified against UsersController.php:48-50 that users/view/0 throws NotFoundException (no special case for 0) while "me" is the actual literal special-cased value, and that PyMISP (api.py:2575) defaults its user param to the string 'me'. The suggested fix (add get_user_me() and fix the doc) was the correct minimal remedy; no broader defect (e.g. in a shared request body) was found in this case.

Caveats

get_user_me_hits_literal_me_path fails before the fix because get_user_me() does not exist yet (compile error), not because an existing test encoded a wrong URL — there was no prior test covering the "me" path to correct. This is a low-severity, additive fix: get_user(i64) is unchanged in behavior aside from its corrected doc comment; get_user_me() is new API surface.

---

Verified locally: cargo fmt --check, cargo clippy --all-targets --all-features -- -D warnings, cargo test --all-features --lib, --test integration_tests --no-run, and cargo check --examples, each in an isolated target directory.

🤖 Generated with Claude Code