Dedicated to the Hydrogen framework, headless commerce, and building custom storefronts using the Storefront API.
Hi there,
I have a merchant who recently installed my app. In my app's admin menu they're getting an AppBridgeError when opening a Resource Picker. The error is APP::ERROR::PERMISSION, which seems to imply that our app doesn't have the right read permissions to view their products/collections, but looking in the app's About menu, it looks like we do.
No other merchants have reported the same issue, and I've asked that the reinstall the app to see if that corrects the issue. Has anyone else ever seen something like this before?
one of my merchants is facing same issue!
For us it was due to needing to update how the createApp is defined.
Originally we had:
var app = createApp({
apiKey: xxxx,
shopOrigin: xxxx
});
It now only seems to need the host from the iframe URL param.
var app = createApp({
apiKey: apiKey,
host: host
});
I'm noticing this happening on staff accounts that don't have sufficient permissions given to them by the store owner when invited. For example, if I invite a staff account to my dev store but only give them permissions to access my app but don't select the "Products" checkbox, any GraphQL query made to Product/Collection resources will fail with this error. I believe this is caused because the access token used in "online" mode is determined from the user's session (so the permissions are constrained to the current user). Presumably, if you also had created an admin api access token in "offline" mode that you saved somewhere, you could perform the GraphQL requests using that. But I'm sure there are potential security implications there.
So that all being said, I'm still not sure what to do with this information. It's not a great UX to have under-permissioned staff accounts jump into our app and have a half-working experience (even if we managed to provide really awesome error messaging in this scenario). I'd love to be able to determine these permission issues ahead of time so we could build features around it instead.