Unable to verify Signature due to invalid HMAC

[jasontxf]

For bug reporting only! If you're posting a feature request or discussion, please ignore.

Expected Behavior

App is able to load within iframe when open from the search bar

Current Behavior

When app load within the iframe, it returns Unable to verify Signature

Failure Information

Steps to Reproduce

Please provide detailed steps for reproducing the issue.

1. Search for your app from the top search bar as shown
   

2. When the app load it will return the following
   

Context

Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

• Package Version: v17.3.2
• Laravel Version: v9.41
• PHP Version: v8.1.0

My guess is the "host" parameter was somehow included which invalidates the HMAC.
However, I'm not able to find where exactly the "host" is being inserted as I seem to have removed all I can find throughout the vendor files.

Would appreciate if you could give me some advise on what's possibly causing it and I could look further into it.

Thanks!

[Kyon147]

Hey @jasontxf the host param is needed, as it is what loads your app into the iframe.

Signature exception is usually because the the API key is not the one from your app settings or that hmac has failed for some reason.

Are you using blade templates?

[jasontxf]

Hello @Kyon147 Yes I'm using blade templates.

It's weird that everything would load properly in the iframe when I remove the host param manually.
But when the host param existed, HMAC don't validate. I don't really understand why.

The API key seems valid since I can still load the app in the iframe.

Oh yes, I forgot to mention this only occurs when you search the app from the search bar and selecting it open a new window.

If you have already pinned the app and simply click on it, it will load in the iframe just fine without opening a new window.
So perhaps it has something to do with redirecting from our main site to the dashboard iframe.

Hope that helps.

Would appreciate it if you could provide me with some advice to troubleshoot.

[Kyon147]

Ah can you try using the new 17.3.3 that I have just published. It might be an issue with the host param on the blade templates.

[jasontxf]

I'm sorry if I'm asking a stupid question, may I know how do I switch to this repository from the previous osiset repo when updating in composer?

[Kyon147]

Hey @jasontxf

The way I usually do it is using in the composer.json

"repositories": [{
   "type": "vcs",
   "url": "https://github.com/Kyon147/laravel-shopify"
 }],

Then just do composer update and this will use my fork and then look for the next version which is 17.3.3

[Kyon147]

@jasontxf any luck with the update - let me know if that did not work as it might be something to do with your implementation.

[jasontxf]

Hello @Kyon147 Thanks for the info on how to update the version. I've just gave it a go and sadly it didn't seems to solve the issue.

Apart from that, my billing seems to be broken now too. But I'll open a new issue for that.

If there's a way to privately msg you, I'll be happy to make a video recording of the entire process and send it to you.
As it contains sensitive company data, I'm not able to post a video recording here.

Please let me know how can I further assist you in this. Thanks!

[jasontxf]

Hello @Kyon147 , just an updates after spending some time troubleshooting I've found the issue but yet to find the root of the issue.

Basically, at VerifyShopify.php @getRequestData within the INPUT switch source, target parameter included the host parameter

Here's a comparison with a working HMAC after removing host parameter from the browser.

As you can see, the target included an extra host parameter.

Then i look at the url at the browser.

https://....myshopify.com/admin/apps/880b4e975174bc3fd1659c4b1ca7d896/authenticate/token?shop=...&target=%2Fdashboard%3FappLoadId%3D7d293aea-e660-483e-ab87-a6e0c13305fb %26host%3DYmxlZWRpbmctcmVsaWMubXlzaG9waWZ5LmNvbS9hZG1pbg

I noticed that the & character was escaped with %26, maybe that's why target identify it as part of the string and thus failing HMAC verification.

I also noticed that even though I removed the host parameter from the browser, during the HMAC verification, host parameter still exists. My guess is Shopify's iFrame included the host parameter as well during the loading of the page.

Which is why when I removed host parameter from the url, everything works as it's properly formatted

So my conclusion is during the redirection from blade, the host parameter probably wasn't parsed properly.

If you could direct me on how the redirection work from external site to embedded app, I might be able to troubleshoot further.

But this is as far I can go based on my own knowledge.

Hope to hear from you soon! I think I'm very close to identifying the root issue. I hope.

[Kyon147]

Hi @jasontxf

The host parameter is needed for Shopify stores, as it contains what url type you are on, either admin.myshopify or xxxxx.myshopify.com/admin and as Shopify are supporting both at the moment they pass it as a base64 encoded string with every request.

This then gets passed into to AppBridge to then get validated for that store along with the other details.

It could be that HMAC is failing because the host param is being included in the validation - I'd need to do some testing to know for sure but I am pretty busy this week with the lead up to Christmas, so might not be until closer to the new year.

[bilfeldt]

@jasontxf I have just tested this on a fresh installation without any problems.

Searching for the app on Shopify and selecting it causes a request with a query like this:

/?embedded=1&host=ZXhhbXBsZS5teXNob3BpZnkuY29tL2FkbWlu&shop=example.myshopify.com&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3Mi....

and this should be verified like so:

To verify the request, you need to remove the hmac parameter from the query string and process it through an HMAC-SHA256 hash function
Source: https://shopify.dev/apps/auth/oauth/getting-started

A few questions:

1. Have you tried veryfying the HMAC manually?
2. have you set the environment variables correctly?

You say that your subsequent requests are working just fine?

[jasontxf]

Hello @bilfeldt

The embedding url is only the beginning of the process I think. After which it will redirect to one of our own blade template which in turn did a redirect to shopify dashboard and open the app in the iframe.

So I suspect is was the blade redirect layer that includes target and host wrongly. But I havent been able to find out which blade did the redirectly exactly as there are a couple of files.

To name a few

• auth/fullpage_redirect.blade.php
• auth/token.blade.php
• billing/fullpage_redirect.blade.php
• layouts/default.blade.php

I tried to comment away the redirect part in javascript and somehow it still got redirected to the shopify app and load in the iframe. So I'm not really sure how it's being redirected.

1. As shown in Unable to verify Signature due to invalid HMAC #6 (comment), I compared the attributes right before the HMAC function is run and identified it's due to the target parameter mixing host together.

https://....myshopify.com/admin/apps/880b4e975174bc3fd1659c4b1ca7d896/authenticate/token?shop=...&target=%2Fdashboard%3FappLoadId%3D7d293aea-e660-483e-ab87-a6e0c13305fb %26host%3DYmxlZWRpbmctcmVsaWMubXlzaG9waWZ5LmNvbS9hZG1pbg

Instead of %26 it should have been "&"

So i'm trying to find out which part of the process convert it into %26

3. There's no host parameter in my environment variables.

Next week I'll give it a go by installing a fresh version of the framework and will let you know when I've identified something new.

Thanks for being patience with me.

[FamousFirstWords]

I believe the issue is with the ampersand being present when decoding the HMAC. I was able to get around this by overriding the verifyHmac() method in VerifyShopify.php

        // We have HMAC, validate it
        $data = $this->getRequestData($request, $hmac['source']);
        foreach ($data as $key => $value) {
            $data[$key] = str_replace('&', '%26', $data[$key]);
        }

[jasontxf]

@FamousFirstWords Thanks for the reply!

Does this mean you have encountered the same issue? It's not just me right?

The ampersand is there because at some point the url have been parsed and special character was being "escaped" and converted into %26