Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Toggle Param to Return Implied Scopes from Remix API Query Method #1604

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

allenchazhoor
Copy link

@allenchazhoor allenchazhoor commented Oct 4, 2024

Issue

Closes https://github.com/Shopify/develop-app-runtime-primitives/issues/507

Context

Currently the query method in the Remix API does not return implied scopes but the response from Core does. This is because Remix is returning a compressed set of scopes from the response from Core, using the toArray() method in AuthScopes.

This PR adds a parameter in the AuthScopes toArray() method to toggle returning the original set of scopes returned from from the Admin API.

Type of change

  • Patch: Bug (non-breaking change which fixes an issue)
  • Minor: New feature (non-breaking change which adds functionality)
  • Major: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

  • I have used pnpm changeset to create a draft changelog entry (do NOT update the CHANGELOG.md files manually)
  • I have added/updated tests for this change
  • I have documented new APIs/updated the documentation for modified APIs (for public APIs)

@allenchazhoor allenchazhoor self-assigned this Oct 4, 2024
@allenchazhoor allenchazhoor requested a review from a team as a code owner October 4, 2024 22:59
Copy link
Contributor

@rezaansyed rezaansyed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Contributor

@RyanDJLee RyanDJLee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking this on - we may want to revisit our test coverage and ensure that it accurately reflects our requirements.

@@ -6,6 +6,7 @@ class AuthScopes {

private compressedScopes: Set<string>;
private expandedScopes: Set<string>;
private originalScopes: Set<string>;
Copy link
Contributor

@RyanDJLee RyanDJLee Oct 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider how the other methods are implemented as well?

The current behaviour considers AuthScopes(['read_products']) equivalent to AuthScopes(['read_products', 'write_products']). Since we are encouraging developers to use this class, I wonder if this behaviour is consistent with the changes proposed in this PR / as part of the Optional scopes feature?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, we would want to keep the scope of this change tight and not introduce breaking changes (by changing the default behaviour). However, I wonder about the developer use cases. Would they want to compare and check inclusion with respect to the exact set of scopes or the expanded set of scopes? What about the other methods?

i.e.

required: ['read_products']
optional: ['write_products']
granted: ['read_products']
  1. Developer queries for optional scopes and instantiates:
requiredScopes = AuthScope(['read_products']);
optionalScopes = AuthScope(['write_products']);
grantedScopes = AuthScope(['read_products']);
  1. Developer wants to check whether the optional scopes have been granted:
grantedScopes.has(optionalScopes);
grantedScopes.equals(optionalScopes);
  • Is this a realistic use case?
  • Is current implementation behaving as expected in these scenarios?

cc @kbav

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants