"Invalid or missing HMAC. Please try re-installing the app." error (v7)

[brettburwell]

Description

Hi y'all, thanks for all of your work on the 7.x branch.

I'm working through the process of creating a store and connecting it to Craft and hit a snag that I'm hoping you can help me with.

I was able to walk through all of the steps outlined in the README, successfully authorize the store, and generate webhooks in my local environment.

When I pushed those changes up to my staging server and attempted to authorize and generate webhooks there, I bumped into an Error authorizing app: Invalid or missing HMAC. Please try re-installing the app. message.

My hunch was that was because the "App URL" I used when creating the app in Shopify's Dev Dashboard didn't match the URL of my staging environment. So I created a new version in the Dev Dashboard, updated the URL to match, and tried authorizing again with the distribution install link. But still no luck.

So then I uninstalled the app in the Shopify admin area, and reinstalled, thinking I just needed to start fresh. Still no luck.

I also pulled down my staging db into my local environment, uninstalled the Shopify plugin entirely and reinstalled, wondering if it it might help to start fresh on the Craft side of things. But I'm still seeing the same error.

I'm guessing I've messed up the order of things on my side, but for the life of me can't sort out what it might be. Any guidance you can provide would be much appreciated! Thanks in advance.

Additional info

• Craft version: 5.8.17
• PHP version: 8.3.30
• Shopify version: 7.x-dev

[linear]

PT-3057

[olsp]

Just for you to know: everytime you publish a new version of the app in the dev dashboard, you can change the App URL. Maybe this would have saved you some trouble

[brettburwell]

@olsp Thanks for the note. Unfortunately, even after updating the app URL I'm still seeing that error. But good thought!

[nfourtythree]

As, has been mentioned you can change the version.

The other option is to create one app for local and one app for your staging. This way you don't have to keep adjusting things and potentially have one or the other stop working.

In terms of trying to diagnose what is going on in your specific scenario, it could potentially be that you may have had a cached access token. Did you try clearing cache at all?

When installing the app in Shopify, I assume you did get redirected to the correct location? Did you see the error straight away or was it after clicking authorise in the Craft control panel?

Thanks!

[brettburwell]

@nfourtythree Thanks for the quick reply.

Totally hear you on creating a new version. In my original comment I mentioned that I already tried that with no luck.

And good call on clearing the caches. I tried that too and the same error is appearing.

Do you think my best option at this stage is just to trash the entire thing and start fresh? Something seems to have gotten tangled up.

My concern is that right now the site isn't live, so I can't use the production url with setting up the app in the Dev Dashboard, and that we're just going to run into this same issue once we're ready for launch.

Or is that not something we need to be worrying about and we've possibly just bumped into something weird here?

[olsp]

@brettburwell I got this (or a similar) error while I had a typo in my variable name in the env file. Did you use "autocomplete" when setting the values for Shopify Client ID / Secret Key, API version and hostname in the Shopify Plugin Settings?

[brettburwell]

@olsp Thanks for chiming in again. I appreciate you trying to help, but unfortunately that's not the issue either (I wish it was something that quick and easy!).

Like @nfourtythree mentioned, it seems like it might be a cached access token. But I've cleared Craft's caches and double checked the database itself, and the craft_shopify_accesstokens row is empty. I've uninstalled and reinstalled the app inside of Shopify, hoping that might help something, but keep running into the same error.

I've triple checked that the currently released version of the app is using the app_url shown in the "Shopify App Auth URL" in the plugin's page in Craft.

I'm stumped about what might be going on.

The only thing I haven't done is trash the entire app in the Shopify Dev Dashboard. I don't want to go down that route yet, because like I mentioned above, I'm hoping to avoiding needing to trash and rebuild the app again once we go live.

@nfourtythree If there's any other info I might be able to pass along that would help with troubleshooting this please let me know! And thanks again.

[brettburwell]

@nfourtythree Another quick followup on this.

I deleted the existing app and started from scratch — hoping that fresh eyes and a clean start might fix things. But after walking through the steps again extra carefully I'm still seeing the same Invalid or missing HMAC. Please try re-installing the app. message.

I've successfully used the plugin (with the old authorization flow) on other sites. And earlier today I was able to successfully get the the plugin to authorize with this project's Shopify store. For the life of me I can't sort out why I'm bumping into this error.

As a quick recap, here's what I've tried to work around the issue:

1. Created a new release of the existing app with an updated App URL that matches our staging url.
2. Rotated the secret.
3. Double and triple checked that the client ID, secret, and other details were set correctly in the .env file (and didn't have spaces, etc.).
4. Uninstalled the Shopify plugin in Craft and reinstalled.
5. Checked the db craft_shopify_accesstokens row for a stale token.
6. Cleared Craft's caches.
7. Logged into the Shopify and Craft admin areas in an incognito mode window (one post suggested that mismatched settings in the browser might trip things up).
8. Deleted the previous app and created a new one.
9. Tested the distribution link in a different browser that I don't typically use.

I realize phantom issues like this are hard (and annoying) to respond to, but I'm honestly not sure what my next step might be. Any insight or suggestions you have would be greatly appreciated. Thanks!

[brettburwell]

Continuing to dig into this issue. This morning I had Claude take a peek at the logs to see if anything jumped out.

Here's what it came back with:

Looking at this new log very carefully, I notice something important in QUERY_STRING:
'QUERY_STRING' => 'p=admin/shopify/auth&hmac=f83d...&host=...&shop=...&timestamp=...'
That p=admin/shopify/auth is being included as part of the query string that gets passed to PHP. Shopify only signed hmac, host, shop, and timestamp — it knows nothing about the p parameter. If the plugin is naively computing the HMAC over the entire $_GET array (which would include p), the verification will always fail because p wasn't part of what Shopify signed.

This is a Cloudways-specific routing issue. Because Cloudways uses Apache with a p= rewrite rule to handle Craft's URL routing, the p parameter bleeds into $_GET alongside the Shopify OAuth params.

To confirm: look at $_GET in the log — it shows p => admin/shopify/auth right alongside the hmac, host, shop, and timestamp params. That p should not be there.

This is likely a bug in the Craft Shopify v7 plugin when run on Cloudways/Apache with query-string-based routing.

This all tracks. Our site is running on Cloudways, which would explain why the auth flow suddenly wouldn't work once I updated the App URL to use the staging URL.

When I updated the site's .htaccess file to change this line:
RewriteRule (.+) index.php?p=$1 [QSA,L]

To this:
RewriteRule (.+) index.php [QSA,L]

I was finally able to authorize successfully and generate webhooks.

Not sure if you're able to handle this edge case directly within the plugin, but if you are, I'm sure it will save some poor souls some future pain.

[nfourtythree]

Hi @brettburwell

Thank you for all of your information. This certainly is incredibly useful. It gives us a path to explore for when we are displaying the Auth URL for developers to be able to copy.

As you found out this needs to be the same in whichever form to ensure that the signatures match for validation.

With this insight we can take a look an see what we can do in making a universal solution that will work for all.

Thanks!