Skip to content

[Issue] fix: correctly scope USPS REST access token cache keys #40813

@m2-assistant

Description

@m2-assistant

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 (*)

  1. Configure two website or store scopes with USPS REST enabled and different USPS REST client IDs.
  2. Clear the Magento cache.
  3. Request USPS rates or another USPS REST action from the first scope.
  4. Request USPS rates or another USPS REST action from the second scope before the first token expires.
  5. 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 (*)

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
  • All automated tests passed successfully (all builds are green)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Priority: P3May be fixed according to the position in the backlog.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    Ready for Development

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions