However, the documentation claims that a host parameter will be passed as part of the query string in the request back to my API during the OAuth handshake.
The issue is that this is not the case. The query string only contains these parameters:
I have written a test in shopify-nextjs-toolbox to prove that all query string parameters are passed correctly. The query string simply just doesn’t have the host parameter that’s needed to instantiate the AppBridge v2 in the frontend.
Can we have an explanation for this? Is there a special parameter we need to set at the start of the OAuth flow to tell Shopify’s API that this is flow needs a host parameter?
Hi everyone, thank you for your patience and being one of the first to jump into upgrading. Really appreciate the fast reporting of this issue.
The fix for the missing host search param during auth is in and it’s currently being rolled out. Some apps should start seeing it today, and more in the next couple of days.
host url parameter is the hostname of the store, used by the App Bridge 2.0 client. It’s a different version of shop as described in the Get and store the shop origin guide.
do I understand correctly that the host parameter is added to the whole OAuth process? Because in our app we’re not using App Bridge or Embedded Apps but the installation is not working because of the failing hmac verification.
We also faced a similar issue.
Just want to ask that every time there is an update of API or params or things like that, will we be noticed via e-mails or other messages? So we are able to prevent possible problems.
And if there won’t be notices, do you have any ideas that what we can do?
Thanks.
We also faced a similar issue.
Just want to ask that every time there is an update of API or params or things like that, will we be noticed via e-mails or other messages? So we are able to prevent possible problems.
And if there won’t be notices, do you have any ideas that what we can do?
Thanks.
It appears that this issue still persists and Shopify has put the permanent fix on backlog.
As a temporary workaround - I recommend 2 things:
Using AppBridge v1 until Shopify releases a fix for this issue. Instead of using the missing host parameter as the instantiating string for the AppBridge, instead you can use shopOrigin (aka *.myshopify.com)
If for some reason you need to use AppBridge v2, unofficially the host parameter is just the shopOrigin base64 encoded. I haven’t verified this myself but I’ve heard from a number of other developers they’re using this as a workaround. However, if Shopify gets around to fixing the host parameter and decides to actually make it more secure by encrypting with your App’s private key instead of encoding - well your authentication could break.
I would recommend v1 over using v2 until we have an official announcement and debrief over what went wrong with the v2 release. I was told back in April a fix was in the works but it’s regressed or was never fixed.
Based on @dylanpierce I would like to add a 3 workaround I discovered on my testing stores, not sure if it works for non-testing stores, it is a little tricky, but until now it has been consistent in my testing stores.
After installation, every time the App is launched from the “Apps” section, the host param will be included in the incoming request params, so in this way, you can design a middleware that grabs and stores this param in a database; and then use it anytime you need it to pass it to AppBridge v2.
During installation, this host param is still not passed at all, so what you can do is to perform a redirect into the parent window, simulating the action of opening the App from the “Apps” section.
After installation, the behavior will be as point 1.