We are running into an issue with our customer account extension. It appears to be recent and we currently know of only one store that brought this up but redirecting from within customer account extensions outside triggers a customer authentication flow after completing authentication however the original path that we were redirecting only retains it’s first param. The examples below will make the issue clear.
The SSO redirect triggers you can see that it has a return_to param but it’s not correctly handling the path inside:
After authentication the return_to only sends the first param and removes any others as it assumes the return_to terminated at the the first & inside the path:
Hey @sandy-stoq
Just to confirm, are you only seeing this behaviour on one specific store, and others work as expected when redirecting?
We were seeing the issue with our integration so it would have affected any store. Only one store complained so I assume the sso_redirect flow doesn’t always trigger.
Hi again,
From digging into this, it looks like this is expected behaviour - Components/parts of urls need to be URI Component encoded (here are MDN docs for how do to this in a browser)
On the image you shared, where the sso_redirect?return_to=somethingsomething?watermarked=true&shopify_order_id=... ? gets cut off at the & this should be part of the return_to and not indicate a new parameter to sso_redirect.
Hi Liam,
Thanks for the suggestion! I appreciate you looking into this, but I’m not sure URL encoding the params will work for our specific use case. Let me provide some additional context that might help clarify the situation.
Our Current Setup: We’re using the to property for the Button component (attached a screenshot below), which expects a proper URL. We pass it a URL to an app proxy page (something like <store domain>/apps/...), and this triggers the SSO redirect the first time we redirect to that URL. Future redirections work normally and don’t trigger the SSO redirect.
The Issue We’re Seeing: Based on what I’m observing in the Network tab, here’s the exact flow:
- First, it redirects to the app proxy URL
<store domain>/apps/...
- This triggers the SSO redirect to the
customer_authentication path we discussed earlier (this only happens on the first visit)
- That’s where the failure occurs if params break.
Why URL Encoding Won’t Work for Us: If I URL encode the params on our end, they won’t be sent correctly to our server when the SSO redirect doesn’t happen. It seems like Shopify should be handling the URL encoding of the path in the return_to param and then decoding it before passing it to our server.
From our perspective, it feels like we shouldn’t need to handle encoded params just to accommodate Shopify’s SSO redirect behavior. Does this make sense, or am I missing something about how this should work?
Overall: We’re seeing several issues with this encoding problem (attaching screenshot of another store running into issues) so it would be good to see if we could get a general idea from the Shopify Engineering team why the encoding isn’t being done and what the ideal solution here is.
Solutions we’ve tried: We are currently using ; instead of & to try and avoid the issue but we’re still running into other issues due to encoding. An alternative we’re working on right now is to use path params like create new paths instead of using URL params (download/orders/1 instead of download?order=1).
