azrepos: make shared token cache configurable - #2415
Conversation
mjcheetham
added
host:azure-repos
There was a problem hiding this comment.
Pull request overview
Adds configurable Azure Repos token-cache isolation while preserving shared-cache behavior by default.
Changes:
- Adds Git and environment settings for cache selection.
- Extends diagnostics to validate both caches.
- Documents interoperability and opt-out behavior.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
src/Microsoft.AzureRepos/AzureReposHostProvider.cs |
Applies the cache setting to Entra authentication. |
src/Microsoft.AzureRepos/AzureDevOpsConstants.cs |
Defines the new setting names. |
src/Core/Diagnostics/EntraAuthenticationDiagnostic.cs |
Diagnoses both token caches. |
src/Core/Commands/DiagnoseCommand.cs |
Formats aggregate diagnostic exceptions. |
docs/environment.md |
Documents the environment variable. |
docs/configuration.md |
Documents the Git configuration option. |
docs/azrepos-users-and-tokens.md |
Explains shared-cache opt-out behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Azure Repos OAuth tokens currently always use the shared Microsoft developer tooling cache. While this enables authentication reuse across GCM, Visual Studio, and Azure CLI, users have no way to isolate GCM's authentication state. Allow users to select a GCM-specific token cache through Git configuration or an environment variable. Keep the shared cache as the default to preserve existing behaviour and document the interoperability and opt-out semantics. Assisted-by: GPT-5.6 Sol Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
The Entra diagnostic only exercises the shared Microsoft developer tools cache. Problems with GCM's application-specific cache can therefore go undetected, while stopping at the first failure would hide the state of the other cache. Run the persistence checks for both caches and collect their failures independently. Flatten aggregate exceptions in the diagnostic log so each cache-specific failure remains visible while the diagnostic still reports a single failure. Assisted-by: GPT-5.6 Sol Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
40e1e3f to
3bfb07f
Compare
| log.AppendLine($"CacheDirectory: {cacheProps.CacheDirectory}"); | ||
| log.AppendLine($"CacheFileName: {cacheProps.CacheFileName}"); | ||
| log.AppendLine($"CacheFilePath: {cacheProps.CacheFilePath}"); | ||
| await RunCacheDiagnosticAsync("Shared Microsoft developer tools", true, log, failures); |
There was a problem hiding this comment.
The diagnostic now tests both caches and throws if either fails. Consequently, a user who explicitly selects the GCM-specific cache can still get a failed git-credential-manager diagnose result solely because the unused shared cache is inaccessible, and vice versa. This is especially misleading because DiagnoseCommand reports that failures indicate an installation problem.
Consider logging results for both caches but making only the configured cache determine diagnostic success, or registering each cache check as a separate diagnostic so the relevant and optional failures are distinguishable.
| ### credential.azreposUseMicrosoftSharedCache | ||
|
|
||
| Use the token cache shared by Microsoft developer tools when authenticating to | ||
| Azure Repos with Microsoft identity OAuth tokens. This allows GCM to reuse | ||
| authentication performed by tools such as Visual Studio and Azure CLI, and | ||
| allows those tools to reuse authentication performed by GCM. |
There was a problem hiding this comment.
These additions say the selected cache allows authentication reuse with Azure CLI. Azure CLI maintains its own cache under $AZURE_CONFIG_DIR/msal_token_cache.{bin,json}, rather than the .IdentityService/msal.cache cache configured here. Any broker-based SSO on supported systems is separate from sharing this cache and may still occur when this option is disabled.
Remove Azure CLI from these examples or describe the narrower set of tools that actually consume the Microsoft developer shared cache.
|
|
||
| --- | ||
|
|
||
| ### GCM_AZREPOS_USE_MSFT_CACHE |
There was a problem hiding this comment.
Same comment seems to apply here from https://github.com/git-ecosystem/git-credential-manager/pull/2415/changes#r3870142015
Azure Repos OAuth tokens currently always use the shared Microsoft developer tooling cache. While this enables authentication reuse across GCM, Visual Studio, and Azure CLI, users have no way to isolate GCM's authentication state.
Allow users to select a GCM-specific token cache through Git configuration or an environment variable. Keep the shared cache as the default to preserve existing behaviour and document the interoperability and opt-out semantics.