1. When a user accepts my billing terms, I send out a request to “/admin/recurring_application_charges.json”
2. My app sends a redirect to confirmation_url extracted from the response body.
3. The user is presented with my billing terms and clicks Accept
4. Shopify does its thing, and eventually sends a request to my App using my specified return_url, but the request status is redirected to /auth.
Im using verifyRequest from koa-shopify-auth, and kao-sessions for my sessions middleware. I’ve got session configured to use a redisStore.
While monitoring my redis server during APP installation, I see the session id, shop, and accessToken being setex
However when the request is made to return_url, there’s a different session id sent. I see redis try to access a non existent session id. Shop then is undefined and verifyRequest middleware fails. I suspect his is what’s causing the redirect to /auth.
Is this correct behavior to send a different session id in the return_url request than what was registered during app installation?
If so, how should i verify requests coming in on return_url?
Meant to say 302 redirect instead of 304 redirect in Subject
Here is my solution:
Initial Steps
- make the fetch with required billing options in the request body:
`https://${shop}/admin/recurring_application_charges.json`
-
Save the shop and charge_id from the response to my backend database.
-
redirect to the confirmation_url extracted from the response.
Work Around
When the shop owner is presented with the confirmation page and accepts, Shopify redirects to the return_url established earlier, BUT without any credentials (as you mentioned above). This fails verifyRequest middleware and redirects the shop owner to my authentication endpoint.
- To avoid this I appended the shop and hmac to the return_url in my recurring_appplication_charge json body defined earlier, and I removed verification of the router intercepting requests to return_url in my app. My return url looked something like this:
`https://${return_url}?hmac=${hmac}&shop=${shop}`
-
Redirects to return_url can now get intercepted by the corresponding router. I use the charge_id appended to the query string by Shopify and the shop to identify and update billing state on my backend. I have not yet tried this, but I suppose you can manually verify the request with the using the hmac in the verification string.
-
Once billing state on my backend is taken care of, I use the shop parameter in the query string and the SHOPIFY_API_KEY to redirect the user to my embedded app page.
`https://${shop}/admin/apps/${SHOPIFY_API_KEY}`
Any feedback on this approach would be appreciated.
Lingering Q’s
- Why would i be getting a different session ID on the return_url redirect?
- Also, according to the documentation, every request and redirect made by Shopify should include hmac in the query string. Any reason why its not being included with the return_url redirect?
1 Like