You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apply six fixes derived from the sibling MSAL PRs (go #629, java #1039,
js #8686) to the forwarded_client_claims port:
1. Make _compute_ext_cache_key injective. Switch from separator-less
key+value concatenation to length-prefixed pairs ("{len(k)}:{k}{len(v)}:{v}"),
matching Go's post-collision-fix CacheExtKeyGenerator. Without this,
fmi_path + client_claims (which now co-occur in acquire_token_for_client)
could collide and return the wrong cached token. Adds boundary-collision
regression tests. NOTE: hashes are now intentionally not byte-identical to
MSAL .NET (which still uses unprefixed concat); caches are not shared across
languages, so within-process injectivity is what matters.
2. Remove the MSIv1 client-side allow-list (_validate_msiv1_claims). Forward
any JSON-object claims value as-is and let IMDS decide which keys it accepts,
matching go/java.
3. Validate the managed-identity source before the cache read. Reject
unsupported sources (Service Fabric, App Service, Machine Learning, Azure Arc)
up front so an unsupported source never returns a cached client-claims token.
_obtain_token keeps its per-source guards as a backstop.
4. Add merge-conflict precedence tests: on a direct leaf conflict the
client-originated value wins (merged last); disjoint claims are preserved.
5. Drop the first-party xms_az_nwperimid example from public docstrings; use
generic "client-originated claims" wording.
6. Document that the same forwarded_client_claims value must be sent on every
request that should share the cached token (it is part of the cache key).
204 tests pass across test_token_cache.py, test_mi.py, test_application.py.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
0 commit comments