Checkpoint.AspNetCore 0.3.2

• net8.0

  • Checkpoint.Core (>= 0.3.2)

0.3.2 — Send detectionClass with log-detection payload

Pre-0.3.2 middleware submitted detection events to
POST /api/v1/log-detection without a detectionClass field. The server
falls back to isAgent ? "ai_agent" : "human", which mis-stamped every
Googlebot, GPTBot, ClaudeBot, SemrushBot, etc. hit as an interactive
AI agent. One hardwareworld.com test window produced 325,056 such
mis-classified rows under source="middleware" in 72 hours.

The detector already produces the correct class in
DetectionResult.DetectionClass. The gap was purely transport — the
DetectionEvent DTO and log-detection payload both dropped the field.
This release closes the gap:

* DetectionEvent gains a nullable DetectionClass property
 (Checkpoint.Core). Nullable preserves binary compat for any caller
 that constructs the DTO manually.
* CheckpointApiClient.TryReportToLogDetectionAsync now emits
 detectionClass in the JSON payload via a wire mapping:
 Human -> "human", AiAgent -> "ai_agent", Bot -> "bot",
 IncompleteData/Unknown -> "incomplete_data". Null omits the field so
 the server's UA-pattern fallback still applies for older callers.
* Both middlewares pass result.DetectionClass through to the
 DetectionEvent — CheckpointMiddleware (AspNetCore, net8.0) and
 CheckpointModule (AspNet, net462) share the same wiring.

Covers all four packages — Checkpoint.Core, Checkpoint.AspNet,
Checkpoint.AspNetCore, and the KyaOs.Checkpoint umbrella.

9 new tests:
* Checkpoint.Core.Tests/Api/CheckpointApiClientPayloadTests (7) —
 per-enum wire assertions + null-omitted + endpoint URL.
* Checkpoint.AspNetCore.Tests/Middleware (2) — bot and AI-agent
 DetectionClass pass-through from detector to DetectionEvent.

Follow-up (out of this release): harden the server fallback at
apps/web/app/api/v1/log-detection/route.ts so older clients that still
omit the field are classified via UA pattern instead of defaulted to
ai_agent.

0.3.1 — Block/Instruct response no longer leaks bad McpServerUrl

Follow-up to 0.3.0. The redirect branches in 0.3.0 correctly refused to
302 to a relative or non-http(s) McpServerUrl, but the block-response
body (PlainText "MCP Server: /connect/x" line, JSON "mcp_server" field)
and Instruct response still propagated the bad URL to the agent. An LLM
fetcher would relay the broken instructions to the user verbatim.

Changes:
* WritePlainTextResponseAsync (AspNetCore): McpServerUrl is gated through
 UrlHelpers.IsAbsoluteHttpUrl — relative / non-http values are dropped
 from the body and the agent gets the "contact site owner" fallback.
* WriteJsonResponseAsync (AspNetCore) + WriteBlockedJsonResponse (AspNet):
 the "mcp_server" / "mcpServer" field is omitted (along with the
 "instructions" sentence) when McpServerUrl is not an absolute http(s)
 URL.
* WriteJsonResponseAsync + WriteInstructResponseAsync (AspNetCore):
 switched from WriteAsJsonAsync to JsonSerializer.Serialize +
 response.WriteAsync. The streaming serializer requires the response
 body PipeWriter to implement UnflushedBytes, which TestServer's pipe
 writer doesn't — every JSON-mode test in the AspNetCore suite was
 silently throwing into FailOpen and falling through to the route
 handler. Buffering matches what the AspNet adapter already does, and
 resolves the four pre-existing test failures inherited from earlier
 releases.

7 new tests in CheckpointMiddlewareTests covering Json/PlainText
McpServerUrl omission across path-relative, schemeless, protocol-relative,
javascript:, and ftp:// inputs. AspNetCore suite now 20/20 green
(was 9/13).