feat(auth): Unity plugin dual-hash metadata + B10 port derivation (d1)#905
Merged
Conversation
Unity-plugin share of auth-fixes task d1. Dual-hash metadata: ProjectInstanceService.BuildMetadata already routes through ConnectionInstanceMetadata.Create, which (in the c1 LIB) emits both the v2 projectPathHash and the legacy v1 projectPathHashLegacy in the hub instance- metadata handshake. Those primitives (ConnectionInstanceMetadata + ProjectIdentity NormalizeV2/DerivePortV2/DeriveProjectPathHashV2) landed in MCP-Plugin-dotnet #165 — one commit AFTER the released McpPlugin 7.1.1 the plugin currently vendors — so the handshake only carries both hashes once the plugin compiles against that LIB build. Vendor a Release/netstandard2.1 dev build of McpPlugin.dll + McpPlugin.Common.dll from MCP-Plugin-dotnet at SHA b5f85828a8ef162c475eb5c2e4f908dd779887f0 into Assets/Plugins/NuGet/ across the plugin + all 5 Unity-Tests projects. The .csproj <HintPath> locations and the McpPlugin NuGet pin (7.1.1) are unchanged; only the binary content is updated. Temporary cross-repo dependency stub — once MCP-Plugin-dotnet ships a release with the dual-hash API, a follow-up (release wave k3) bumps the NuGet folder + <HintPath> to that version and replaces the DLL. B10: Runtime/UnityMcpPlugin.cs GeneratePortFromDirectory now derives the port via ProjectIdentity.DerivePortV2 (v2 normalization: trim trailing separators, '\'->'/', ToLowerInvariant) instead of hashing the raw untrimmed Environment.CurrentDirectory, so the local port stays in lock-step with the routing pin. Added a testable overload. Tests: PortDerivationV2Tests (B10 port normalization, anchored to the v2 golden vectors) + dual-hash coverage in ProjectInstanceServiceTests (both hashes present and distinct on a Windows path, both carried as hub query params). The DoD's E2E repro (window Authorize -> agent sees engine tools, not 3) is DEFERRED: per k1 (design 01 §7) the B11 root cause is a server/LIB audience-mismatch whose fix lands in task c2 (LIB), not here; re-verified at k2. Closes #904
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Unity-plugin share of auth-fixes task d1:
projectPathHashand the legacy v1projectPathHashLegacy, so a session pinned by an OLD (v1-pin) config still matches this NEW plugin (dual-hash transition / defect B5).ProjectInstanceService.BuildMetadataalready routes throughConnectionInstanceMetadata.Create, which emits both hashes — the send path needed no plugin source change; it just needed to compile against the c1 LIB primitives.Runtime/UnityMcpPlugin.csGeneratePortFromDirectoryderives the deterministic local port viaProjectIdentity.DerivePortV2(v2 normalization: trim trailing separators,\→/,ToLowerInvariant) instead of hashing the raw, untrimmedEnvironment.CurrentDirectory, keeping the local port in lock-step with the routing pin. Added a testable overload.Cross-repo dependency stub (dev DLL)
The dual-hash + v2 primitives (
ConnectionInstanceMetadata.projectPathHashLegacy,ProjectIdentity.NormalizeV2/DerivePortV2/DeriveProjectPathHashV2) landed inIvanMurzak/MCP-Plugin-dotnet#165 — one commit after the released McpPlugin 7.1.1 the plugin currently vendors. This PR therefore vendors a Release/netstandard2.1 dev build ofMcpPlugin.dll+McpPlugin.Common.dllfrom MCP-Plugin-dotnet at SHAb5f85828a8ef162c475eb5c2e4f908dd779887f0intoAssets/Plugins/NuGet/across the plugin + all 5 Unity-Tests projects. The.csproj<HintPath>locations and the McpPlugin NuGet pin (7.1.1) are unchanged; only the binary content is updated. Temporary stub — once MCP-Plugin-dotnet ships a release with this API, a follow-up (release wave k3) bumps the NuGet folder +<HintPath>and replaces the DLL.Deferred (gated on task c2)
The DoD's E2E repro — window Authorize → agent sees engine tools, not 3 — is not verified here. Per k1's code-trace (design
01-current-architecture.md§7) the B11 "3 tools" root cause is a server/LIB audience-validation asymmetry at the instance-registration validator, whose fix lands in task c2 (LIB), not in the Unity plugin. The plugin's own behaviour is correct; this repro is re-checked at k2 once c2 lands.Test plan
failing=0across all fixtures; onlyTestsRunDirtySceneTestsis a transport-timeout (native-runner-only, CI-covered) — green per profile carve-out. No known-flakes fired.PortDerivationV2Tests(11) — port normalization anchored to the v2 golden vectors (backslash/forward-slash/trailing-slash converge).ProjectInstanceServiceTests.BuildMetadata_SendsDualHash_V2PrimaryAndLegacyV1+BuildMetadata_ToQuery_CarriesBothHashKeys— dual-hash visible in the handshake payload + query params.Closes #904