Fallback se:// URI generation when secrets engine is unreachable#448
Fallback se:// URI generation when secrets engine is unreachable#448saucow merged 2 commits intodocker:mainfrom
Conversation
When GetSecrets() fails (e.g. MSIX-sandboxed Claude Desktop on Windows cannot follow AF_UNIX reparse points to the WSL2 secrets engine socket), generate se:// URIs for all declared secrets instead of silently setting them to <UNKNOWN>. Docker Desktop resolves se:// URIs at container runtime via named pipes, which are unaffected by MSIX restrictions. Also log the GetSecrets() error instead of silently discarding it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
slimslenderslacks
left a comment
slimslenderslacks
left a comment
There was a problem hiding this comment.
What about the case where secrets can't be resolved, but there are also oauth secrets to resolve? I'll bet you're looking forward to refactoring this code more comprehensively.
|
|
||
| // availableSecrets maps secret IDs to their values (used to check existence) | ||
| allSecrets, _ := secret.GetSecrets(ctx) | ||
| allSecrets, err := secret.GetSecrets(ctx) |
There was a problem hiding this comment.
What about passing availableSecrets into this function (possibly empty), and treating this as another fallback? Would that make this simpler?
There was a problem hiding this comment.
That's a good point, I opted for an approach which updates: BuildSecretsURIs to have two clear paths:
-
- GetSecrets() succeeds →
buildVerifiedURIs()generatesse://URIs only for secrets that actually exist in the store (OAuth token checked first, then direct secret)
- GetSecrets() succeeds →
-
- GetSecrets() fails →
buildFallbackURIs()generatesse://URIs for all declared secrets since we can't check existence (OAuth preferred when configured, matching normal priority
- GetSecrets() fails →
Refactored into separate functions for clarity: - buildFallbackURIs: generates se:// URIs for all declared secrets when the secrets engine is unreachable (OAuth preferred when configured) - buildVerifiedURIs: generates se:// URIs only for secrets that exist in the store (OAuth checked first, then direct secret) - oauthMapping: shared helper for OAuth provider lookup When GetSecrets() fails (e.g. MSIX sandbox on Windows), the fallback generates URIs for everything and lets Docker Desktop resolve at runtime. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@slimslenderslacks Good point, updated so:
Yes it's definitely needed! |
* Fallback se:// URI generation when secrets engine is unreachable When GetSecrets() fails (e.g. MSIX-sandboxed Claude Desktop on Windows cannot follow AF_UNIX reparse points to the WSL2 secrets engine socket), generate se:// URIs for all declared secrets instead of silently setting them to <UNKNOWN>. Docker Desktop resolves se:// URIs at container runtime via named pipes, which are unaffected by MSIX restrictions. Also log the GetSecrets() error instead of silently discarding it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Address PR feedback: handle OAuth secrets in fallback path Refactored into separate functions for clarity: - buildFallbackURIs: generates se:// URIs for all declared secrets when the secrets engine is unreachable (OAuth preferred when configured) - buildVerifiedURIs: generates se:// URIs only for secrets that exist in the store (OAuth checked first, then direct secret) - oauthMapping: shared helper for OAuth provider lookup When GetSecrets() fails (e.g. MSIX sandbox on Windows), the fallback generates URIs for everything and lets Docker Desktop resolve at runtime. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3 participants
What I did
When GetSecrets() fails (e.g. MSIX-sandboxed Claude Desktop on Windows cannot follow AF_UNIX reparse points to the WSL2 secrets engine socket), generate se:// URIs for all declared secrets instead of silently setting them to . Docker Desktop resolves se:// URIs at container runtime via named pipes, which are unaffected by MSIX restrictions.
Also log the GetSecrets() error instead of silently discarding it.
Related issue
#443 #424