Skip to content

Let a caller wrap the client's HTTP handler, to see and refuse each request - #464

Merged
davidnmbond merged 1 commit into
mainfrom
feature/wrap-http-message-handler
Nov 6, 2026
Merged

davidnmbond merged 1 commit into
mainfrom
feature/wrap-http-message-handler

Conversation

@davidnmbond

Copy link
Copy Markdown
Collaborator

Closes #463.

Adds MerakiClientOptions.WrapHttpMessageHandler (Func<HttpMessageHandler, HttpMessageHandler>?). The client calls it once at construction with its own AuthenticatedBackingOffHttpClientHandler and builds its three HttpClients (core, SecureConnect, Workflows) on the result, so a caller can see, record and refuse every request. Sitting outside authentication and retries, the wrapper sees one call per request with its final response and never the credentials. Disposing the client disposes it. A wrapper returning null is a ConfigurationException. Unset, nothing changes.

Why: Magic Suite (MS-28068, SOC 2) hands this client to customers' C# scripts and must audit every write, who caused it, its method, path and outcome, and refuse writes itself when they are not permitted. The other PanoramicData API clients will follow the same option name.

Tests: Meraki.Api.Test.Client.WrapHttpMessageHandlerTests (offline: the wrapper sees the request and its answer is the client's answer; a refusal fails the call with its reason; the wrapper is created once around the client's own handler; a null wrapper is a configuration error; disposing the client disposes the wrapper). Red check: with the HttpClients built on the unwrapped handler, the two request tests fail. Release build clean; all 81 tests in Meraki.Api.Test.Client pass.

The changelog entry is headed Unreleased, for the version it ships in. Making IsReadOnly immutable after construction is not part of this change.

…equest (#463)

MerakiClientOptions.WrapHttpMessageHandler is called once at construction with the client's own handler; the three HttpClients share the wrapper, which sits outside authentication and retries.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@codacy-production

codacy-production Bot commented Nov 6, 2026 •

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 11 complexity

Metric Results
Complexity 11

View in Codacy

🟢 Coverage 100.00% diff coverage · +0.03% coverage variation

Metric Results
Coverage variation ✅ +0.03% coverage variation
Diff coverage ✅ 100.00% diff coverage

View coverage diff in Codacy

Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (00dc0d1) 8067 3148 39.02%
Head commit (39ed3dd) 8071 (+4) 3152 (+4) 39.05% (+0.03%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#464) 7 7 100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

AI Reviewer: run a review on demand. To trigger the first review automatically, go to your organization or repository integration settings. AI can make mistakes. Always validate suggestions.

Run reviewer

TIP This summary will be updated as you push new changes.

@davidnmbond
davidnmbond merged commit 950d8d8 into main Nov 6, 2026
8 checks passed
@davidnmbond
davidnmbond deleted the feature/wrap-http-message-handler branch November 6, 2026 21:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Let a caller wrap the client's HTTP handler, to see and refuse each request

1 participant