Expired accessToken when handling app/uninstalled webhook

Solved
artooras
Shopify Partner
22 0 8

I have successfully registered and receive app/uninstalled webhook events in my app. When I receive such an event, I want to remove the data that was added when my app was installed using the Admin API.

 

The issue is that even though I am able to retrieve the accessToken from my external session store, when I try to use the accessToken for an authenticated request to Admin APIs, I get the following error:

 

 

HttpResponseError: Received an error response (401 Unauthorized) from Shopify:
"[API] Invalid API key or access token (unrecognized login or wrong password)"

 

 

I guess in a way it is logical if this webhook is sent after the app has been uninstalled and client session invalidated. But, if that is the case, how do I clean up data if the accessToken has expired?

Accepted Solution (1)

Accepted Solutions
JayAdra
Shopify Partner
52 5 8

This is an accepted solution.

It's not ideal, but this is just the way it is. Basically the way we handle it is the same.

 

When we receive the app/uninstalled webhook, we attempt to call an API using the access token. If the call fails with that 401 error, we assume that to mean they have uninstalled and we then clean up their information in our database. If the access token works, it means they have re-installed or similar, and therefore we just leave everything as is.

 

If you have data within the merchant's store that you want to remove/clean up, then you're out of luck unfortunately. Once they uninstall, you lose access. This is why apps that add/edit theme files can be so dodgy - those files can't be removed on uninstall (unless you're using ScriptTags or App Blocks).

 

In the end, it just comes down to the app's design and how it functions. You should always try to design your app so that if it does have to leave some info/files behind, that they are unobtrusive. Ideally it would leave nothing behind though.

View solution in original post

Replies 3 (3)
JayAdra
Shopify Partner
52 5 8

This is an accepted solution.

It's not ideal, but this is just the way it is. Basically the way we handle it is the same.

 

When we receive the app/uninstalled webhook, we attempt to call an API using the access token. If the call fails with that 401 error, we assume that to mean they have uninstalled and we then clean up their information in our database. If the access token works, it means they have re-installed or similar, and therefore we just leave everything as is.

 

If you have data within the merchant's store that you want to remove/clean up, then you're out of luck unfortunately. Once they uninstall, you lose access. This is why apps that add/edit theme files can be so dodgy - those files can't be removed on uninstall (unless you're using ScriptTags or App Blocks).

 

In the end, it just comes down to the app's design and how it functions. You should always try to design your app so that if it does have to leave some info/files behind, that they are unobtrusive. Ideally it would leave nothing behind though.

artooras
Shopify Partner
22 0 8

I can kind of understand the reasons behind invalidating tokens on uninstall. At the same time, it would also make sense to invalidate the tokens, say, 5 minutes after uninstall, to allow app developers to clean up their changes to the shop/theme.

JayAdra
Shopify Partner
52 5 8

While this sounds good in theory, and would be awesome for 99% of apps, it would allow for some dangerous things. Maybe a store owner finds an app accessing data they don't want to share, or causing some issue within their store. If they can't revoke access immediately, it gives a chance for the app to cause further harm, and maybe even run some spite code upon uninstall or similar.

 

It makes sense for the store owner to be able to immediately remove an app, but it also makes sense to give us app developers a way to clean up properly. I'm not sure what a better solution would be. For now, we just need to design our apps to be unobtrusive as best we can, and avoid the old methods of adding/editing theme files.