This issue is automatically created based on existing pull request: #40806: fix: correctly scope USPS REST access token cache keys
Description (*)
This pull request fixes USPS REST OAuth token caching so that access tokens are not shared across different USPS REST client credentials.
Previously, Magento\Usps\Model\UspsAuth::getAccessToken() always used the fixed cache key usps_api_token_. In a multi-website or multi-store setup with different USPS REST credentials, one scope could reuse a bearer token that was fetched for another scope.
The cache key now includes the OAuth token endpoint, client ID and requested OAuth scope. The client secret is not included in the cache key.
Unit coverage has been updated to check the scoped cache key behaviour, including a case where two different client IDs on the same endpoint read different cached tokens.
Manual testing scenarios (*)
- Configure two website or store scopes with USPS REST enabled and different USPS REST client IDs.
- Clear the Magento cache.
- Request USPS rates or another USPS REST action from the first scope.
- Request USPS rates or another USPS REST action from the second scope before the first token expires.
- Confirm that each scope uses a token cached for its own USPS REST client ID and token endpoint.
Questions or comments
With the original cache key being just self::CACHE_KEY_PREFIX makes me wonder if this is a half complete feature thats been released, or just not properly code reviewed?
Contribution checklist (*)
This issue is automatically created based on existing pull request: #40806: fix: correctly scope USPS REST access token cache keys
Description (*)
This pull request fixes USPS REST OAuth token caching so that access tokens are not shared across different USPS REST client credentials.
Previously,
Magento\Usps\Model\UspsAuth::getAccessToken()always used the fixed cache keyusps_api_token_. In a multi-website or multi-store setup with different USPS REST credentials, one scope could reuse a bearer token that was fetched for another scope.The cache key now includes the OAuth token endpoint, client ID and requested OAuth scope. The client secret is not included in the cache key.
Unit coverage has been updated to check the scoped cache key behaviour, including a case where two different client IDs on the same endpoint read different cached tokens.
Manual testing scenarios (*)
Questions or comments
With the original cache key being just
self::CACHE_KEY_PREFIXmakes me wonder if this is a half complete feature thats been released, or just not properly code reviewed?Contribution checklist (*)