fix(security): redact credentials in JSON and form bodies under --verbose

[gyanranjanpanda]

Problem

Commit 0f8b000 (closes #449) added redactSensitiveContent to verbose HTTP dumps. It works for Authorization headers but the sensitiveParamPattern regex only matches name=value (form encoding). Both dump sites that carry secrets produce JSON bodies, so the pattern never fires.

Leak 1 — keycloak_client.go:96: Keycloak token response body is JSON. access_token, refresh_token, and id_token print verbatim.

Leak 2 — microcks_client.go:371: OAuth2ClientContext is marshalled into the POST /api/tests body. clientSecret, password, and refreshToken are not in the pattern at all.

The Authorization: [REDACTED] header line makes the output look safe, masking the residual exposure.

Tracked in #503.

Fix

Replace the single catch-all regex with a structured approach:

• JSON bodies — parse with encoding/json, redact sensitive keys by name
• Form bodies — parse with url.ParseQuery, redact by key name
• Unknown/chunked — text-pattern fallback

Key matching normalises snake_case, camelCase, and kebab-case so every spelling variant is covered (access_token, accessToken, Access-Token all match).

Non-sensitive metadata (token_type, expires_in, serviceId) is preserved so --verbose stays useful.

Tests

pkg/config/config_test.go — 13 tests (all new), covering:

• JSON token response (regression for Leak 1)
• JSON test request with oAuth2Context (regression for Leak 2)
• Form-encoded token exchange
• Nested/array JSON
• Chunked transfer fallback
• Header-only dumps
• Non-sensitive body preservation
• CRLF round-trip
• Key normalisation variants
• End-to-end through DumpRequestIfRequired / DumpResponseIfRequired

ok  github.com/microcks/microcks-cli/pkg/config  0.657s

[Caesarsage]

This is good.

I left a comment. Also, could you reduce the comments , it is making the code unnecessarily large and noisy. comments is only useful where it is really needed like on the complex regex and should be simple

[Caesarsage]

One gap here: authToken / auth-token values leak through — authtoken isn't in sensitiveValueKeys, and auth-token is the exact key the CLI's own config uses:

dump := "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\n\r\n" +
{"authToken":"eyJPROBELEAK"}
redactSensitiveContent(dump) // value survives
Adding "authtoken": {} to the set covers both spellings via the normalizer.

Minor, non-blocking: json.Marshal re-encoding reorders keys and HTML-escapes, so dumped bodies aren't byte-faithful (and won't match Content-Length) — worth a one-line code comment.