A space to discuss GraphQL queries, mutations, troubleshooting, throttling, and best practices.
Hello,
How can I request additional access scopes after install? Bascially, a prompt appears saying in order to view products this app requires read products access scope. I don't expect a lot of people to use this feature, so I'd like to have the access scope optional.
So is there a way to basically redirect the user to a grant additional access page similar to the billing subscription flow? I swear I've seen some apps do this in the past. I've searched through GQL docs and doesn't seem possible with GQL.
Hey, thanks for your reply!
I've practically done all that you've said. The part i'm stuck on is the part on how to request Shopify to prompt the user that the app requires additional access.
Also, how would you "Redirect to the app installation page", you mean the Shopify app installation page? I don't think that's possible.
Apologies, but is that reply from Chat GPT?
Apologies, but I feel it was. The structure. The way the code is structured, with comments. The capitalised Shopify Partner API. The bullet point list structure of possible solutions. Then with this reply, the structure is completely different, and all lower case chat gpt.
Uthman, was your previous responses from Chat GPT?
Hi,
Could you provide more context on your app's environment? Is your app embedded app?
It's a quite common use case as you add more features, your app may require additional access scope for stores that already have your app installed.
For example, the remix based embedded app will automatically prompt the store to review and authorize the new scopes (the same screen as the initial install), if Shopify detects your current app version requires more scopes than already authorized. Sounds like this is what you wanted?
Hey,
Yeah I'm using Shopifys remix template. I'm aware that changing the access scopes required for the app will prompt users again to grant additional access. For some access scopes, I don't want to require them immediately from the user. Only when it's necessary, say when they want to view products, the app will then prompt them with a request access for "read_products", which then it would redirect them to a Shopify page to grant additional access for the app.
This Shopify app kinda does it, in an interesting way.
https://shopify-graphiql-app.shopifycloud.com/login
Hmm... that's an interesting use case. The OAuth authorization is at store->app level - you kind of want the access control at feature/page level... I doubt it would work for the Shopify remix template - you might need to heavily customise it, unless the deferred authorization is critical for your app it might not be worth to do, as it doesn't seem to be a common practice.
"Shopify GraphiQL App Installer" is probably not a good comparison as it's designed to be a GraphQL testing tool which needs that level of fine-grained API scope.
Deferred authorization is the best way to describe it!
I'm hoping to try and figure it out, as some users will avoid an app for privacy concerns or they don't understand why the app would require certain permissions when its outside of the apps niche. i.e, product editing app requiring access to read orders.
I pointed out "Shopify GraphiQL App Installer" as it doesn't hard code every access scope in the access_scope > scope: string value in the shopify.app.toml file, it's dynamic in a way. Whatever scope you pick, it appears in Shopifys prompt for what access scopes the app requires.
I'm curious on how to apply that to an app after its installed, click a button, redirect to shopify page, this app is requesting additional access. Similar to the billing flow, you click upgrade to paid subscription, the app redirects you to Shopifys billing page, and then redirects you back to app.
Right, I guess "Shopify GraphiQL App Installer" is not based on the remix template. You might need to handle the auth directly with the lower level SDKs to have that fine-grained control.
Regarding the user's concerns about privacy, in my opinion, if you can demonstrate the access needs, such as in the privacy policy, explaining what data and how you use it exactly, it shouldn't scare them away (unless you're dealing with super sensitive data...).
Product and order are closely related because the order item is the product - it is reasonable to have read-only order access if a feature requires it. I think the most important thing here is that your app is compliant with data privacy and protection regulations.
That makes sense, but I'll probably not stray away from the remix template. I'll try an dig deeper. What do you mean by lower level SDKs?
I agree on your point about the privacy concerns, however, in my experience, users aren't that gracious and most don't dig deeper into the privacy policy. If they see something they don't understand, they'll just move on. I'd like to avoid that, and then present them the reason why it is needed (optional) in front of them. I guess product and order are closely related, but that wasn't my point. The point was two different access scope an app requires but wouldn't necessarily need, resulting in just giving the user concerns (why would an app that does ... need to have access to ...?)
Right.
For lower level JS SDKs, for example:
https://github.com/Shopify/shopify-app-js/tree/main/packages/apps/shopify-api
(since you needed to implement the OAuth token exchange)