If you follow the instructions to scaffold an app with the Shopify CLI, you’ll end up with an app that, strangely, requests personal data on install. Here’s the screenshot from Shopify’s own tutorial:
This is an otherwise default configuration, and I can’t see anything that would indicate additional data being requested. I have not requested access to data in the partner dashboard, and the store is the default dev store (though I’ve added some things and played with it a bit). But the fact that the scaffold app docs show a request for personal data suggests to me there is a deeper issue here.
I’ve raised an issue with shopify support, but I’m wondering if anyone here has had success removing these access requests for newly scaffolded apps.
The read_orders scope requires access to customer’s PII since the order contains the customer’s name, email, phone number, shipping, billing, IP address and more.
However, for a development app you can get instant approval for viewing this data. You’ll just need to fill out the form in the Partner Dashboard for your app.
In development mode, the permission is granted instantly.
Alternatively, you can remove that access scope and use a different one instead.
My reading of those docs was that the intention is to separate out the sensitive bits of those scopes, but not the whole thing. Graphql lets you query just the info you need – why not divide up the scopes a bit more so that one can access non-identifying order data without having to have users grant a whole lot of trust they don’t really need to grant? “customer”, for example, already has its own scope, and accessing that field within the Order will give an error. Why not also scope the address or whatever else is problematic? The current implementation can give apps much more than they need, apparently.
Also, why does the default scaffold app require merchant protected data? Is this just the default for all apps?
You’ve got that part right, access scopes allow you to narrow down exactly what information your apps need and no more.
why not divide up the scopes a bit more so that one can access non-identifying order data without having to have users grant a whole lot of trust they don’t really need to grant?
Perhaps you can share a bit more details about the non-PII related order data you need for your app?
Maybe there’s already a specific access scope out there for your use case.
Either way, listing these out helps the Shopifolk reading these forums know about your use case and it can help guide them make more granular scopes in the future.
Also, why does the default scaffold app require merchant protected data? Is this just the default for all apps?
Just might be a small DX choice. An order is a familiar concept to even the newest developer to the eCommerce space. Whereas other areas might not be so intuitive. An order is pretty universal.
Perhaps you can share a bit more details about the non-PII related order data you need for your app? Maybe there’s already a specific access scope out there for your use case.
There is a lot of order data that has nothing to do with customer information. For example, which products were part of the order, in what quantity, and at what prices. That’s the information I’m after.
Apparently the order scope is quite broad. It’s surprising to me they have carved out a returns scope but not a customers scope. To get the amount of an order one has to request “protected” customer data.
Shopify’s Admin API is going through a REST → GraphQL transition, and perhaps in the future when this is complete it’ll be possible to have per-property scopes so you can only request these non-PII fields on an order.
But I believe the reason why the read_order scope is so wide is because it’s tied to the original Order resource in the REST API.
