Hi !
I’m building an app that uses the App Proxy feature. I’m relying on the HTTP_X_SHOPIFY_CLIENT_IP header from the proxied request, and quite often this header is missing.
Do you have input on what may cause its absence ? Should we never rely on it?
Thanks ! Adrien
Hey Adrien,
I haven’t been able to replicate the missing header at all. Did you happen to notice if it’s only missing when certain events take place by chance?
I’m not aware of any reason for it to be missing off-hand, but if it is essential for you and you find that it’s missing sometimes I definitely wouldn’t want to recommend relying on it.
Hi @Josh ! Thank you for your answer. I have not noticed anything specific, it feels very random so far. It happens on the same URL for the same devices. I could not find a precise workflow that would trigger it. however it is quite frequent.
My Rails code that catches it looks like this:
if request.headers["HTTP_X_SHOPIFY_CLIENT_IP"].blank?
Monitoring.capture_exception(
Exception.new("missing headers for auth"),
level: 'warning'
)
end
It’s quite hard for me to do what I’m aiming at without this header.
What could I do to help you debug this? I could provide you with a unique request identifier that you could look at later? Do you know which ID I should get for you?
Thanks! Adrien
Hey again Adrien,
We could try the HTTP_X_REQUEST_ID header if you don’t mind posting that, if you could grab one from a request that did work and then one that did not that would be an additional bonus (but not a requirement).
I’m not sure that our logs will contain enough information to see what is causing this if I’m being honest, but it’s certainly worth taking a look. I’ve sent requests to my own proxy from Chrome, Firefox, Safari, and an HTTP client and they all had an IP address attached - so this one is still very much a mystery I’d like to get to the bottom of.
Thanks for taking this seriously @Josh ! I’ve just added instrumentation to be able to give you these IDs, I’m deploying them and I’ll let you know as soon as I have some data. Have a nice day!
Hello @Josh ! Here is a first request that just happened on the shop joone-test01.myshopify.com and that didn’t have the HTTP_X_SHOPIFY_CLIENT_IP HTTP header. It’s HTTP_X_REQUEST_ID is : d7c66797-c2dc-49b6-8522-dc95bf547416
Thanks so much for taking the time and don’t hesitate to reach out in private too I’d be happy to provide more information.
Have a nice day,
Adrien
Hey again Adrien,
Sorry for the delay here - I was away at our Unite conference all last week.
Is there a chance that the request that ID came from is over 12 days old? When I check our logs with it, nothing is there.
Hi @Josh ! Thanks for following up and no worries, the conference sounded intense, so many features we’re looking forward to !
I don’t think the request was 12 days old, but in any case here are a few other random ones from the production shop jooneparis.myshopify.com :
63f3fa1a-0b8e-4ed3-b6b7-53d793519799 June 25 2019 08:49:50 CEST
177d67b1-76c6-4d26-a6f9-2c5e6b79325b June 25 2019 08:48:11 CEST
ace68225-2ace-4394-ae8c-fa687103d0f0 June 24 2019 22:30:02 CEST
(just to repeat, there are the values for the HTTP_X_SHOPIFY_CLIENT_IP header for requests that were missing a HTTP_X_SHOPIFY_CLIENT_IP header)
I’ve setup sentry monitoring for this issue on this rather big shop and here are the volumes for this warning:
Thank you
Hi @Josh - You can see all HTTP_* headers forwarded to our server, here: https://smart-eu-cookie-banner.myshopify.com/tools/privacy?debug=true
HTTP_X_SHOPIFY_CLIENT_IP is missing, but HTTP_X_FORWARDED_FOR is present. We now have a cascade of if statements to fetch the client address. HTTP_X_FORWARDED_FOR seems to include both the client address and Shopify’s proxy server, so we split on ‘,’ and take the first value.
Our use case is country detection so we also fall back to Cloudflare’s country header, when present. Hope this helps!
@Impress thanks for the tip ! I didn’t know notice that both addresses were included in the HTTP_X_FORWARDED_FOR, I’ll try fallbacking on this now
@Impress Thanks a ton for chiming in here, this was a weird one - these events aren’t generating logs on our end and I haven’t been able to replicate the problem either, so I was at a loss.
@adrien2 If this ends up being an acceptable solution, would you mind making sure you click the ‘Accept as Solution’ button on the relevant comment? I’m sure this will end up being valuable information for others in the future.
Hi @Josh ! I haven’t yet updated my code to fallback on this other header. I’ll make sure to tell you if this covers all cases and if I’m not seeing any new cases. I have to say it’s not a super satisfying answer to learn that we have no idea why this header is not sent ? but I can mark this topic as closed if you want me to, sure.
