Hello! This is driving me absolutely crazy, so asking here in case I’ve missed something major.
I have a backend app that is accessed via the app proxy.
The backend app needs a verified the customer ID to know which data to modify / display.
We’re using new customer accounts (passwordless login).
We started out implementing with logged_in_customer_id, but then discovered it doesn’t get set for new customer accounts.
So we pivoted to using authenticate.public.appProxy() on the backend, but while that works to authenticate the request and give us an admin/storefront graphql entry points, I can’t see any way to get the currently logged in customer info with that.
This is a custom (private) app, so I would hope we could qualify for the extra approval to access customer info. But even so, right now I’d just be happy with any kind of customer identifier that is ‘verified’ (ie: not injected by the customer with javascript).
I see there are ways to redirect the customer to verify the access and then come back to the app, but that’s a horrid solution for functionality that’s supposed to be embedded in the site (buttons that change status and such).
This HAS to be a thing, right? There HAS to be a way to get basic info about the currently logged in customer data from inside your app…?
Please help - I’ve been searching for a week and I feel like I’m taking crazy pills!
Hey @confusionlimited - this is a known issue with the App Proxy and logged_in_customer_id values. We are currently looking at is a possible bug, but I can’t guarantee an exact turnaround time for a fix.
I’m going to add your report to our internal tracking though, just so we have that noted on our end.
In terms of a workaround, I would say that your method that leverages the new Customer Accounts API to grab the access token would be the best bet, although I definitely understand that requiring an in-browser redirect isn’t ideal. This might help with setting up the authentication flow using the new Customer Accounts API: Customer Account API reference
I’ll keep an eye on things on our end here though regarding the logged_in_customer_id field and loop back with you when I have more info to share.
Let me know if I can clarify anything on our end here!
First: thank you for your reply, at the very least I now know I’m not missing anything obvious.
That said, this missing feature is a complete blocker. I’m attempting to move a company with 4+ million in sales from their current custom built site to Shopify, and their minimum required functionality needs to be able to tell if a user is logged in or not, and at minimum a user ID. Without this I am unable to complete the move.
I don’t mind doing a couple extra API calls to get this info, if that’s an option, but the “redirect the user” is not a workaround that will be feasible for them, and we cannot continue without a user identifier.
If there really is no other way to determine the user, and the fix for logged_in_customer_id is undetermined (or far in the future), then I simply cannot move them to Shopify.
Hey @confusionlimited ,right now there isn’t an easy workaround for App Proxy specifically when it comes to pulling the logged-in customer info , but one possibly feasible workaround (depending on your use case) would be to use the Customer Account API in combination with a Hydrogen storefront.
This would let you/the merchant authenticate customers and access their “current” log-in info, but it does require a full headless setup and still involves the customer going through the authorization/login flow (a bit more info here). It is a little more robust, but also requires more infrastructure, so I definitely understand if that’s not ideal.
I’ll keep digging to see if there are any other possible workarounds that other folks on the team may know of, but I just wanted to touch base and share that —let me know if you have any questions or want to discuss the Hydrogen approach in more detail.
As @Alan_G has said, this is a known issue, and is on our backlog to fix, but we haven’t been able to get to it yet.
I’m guessing the reason they need the logged in customer id is to make an API call to the admin API while ensuring the id being passed to your app proxy really is the id of the logged in customer. Could you share more details about the data you need to query via your app proxy? Would you be able to store that data in customer metafields, which are accessible in liquid?
So ive recently by this bug where a user logged in on the store stopped sending logged_in_customer_id, which was working perfectly fine the day before.
From what i can tell its a dodgy server in the proxy cluster. Because my app also gets a custom cookie that ive set if there is no logged in customer id.
And now some days i get this other cookie for requests and if ive logged out and logged in i get the other cookie.
So it seems to be which proxy does the proxying, im assuming they have some local cache and there is some stickines to which server you get proxying. Because i can go days without seeing the bug
Update: We’ve just released a fix for this. The fix won’t affect sessions that were already created before this, but sessions that are saved now should last 30 days.
Hi @Liam-Shopify I am still seeing the empty logged_in_customer_id in the proxy query. Is there anything we need to do our side in order to get this fix working?
Given that it’s been a little while since fix went out and sessions are supposed to last 30 days, any active customers should have cycled through new sessions by now, very strange for sure.
Can you share a bit more detail about your setup, specifically whether you’re using New Customer Accounts (passwordless login) or classic accounts, and whether this is happening consistently or intermittently? It sounds like this might be either a separate issue from what was fixed in June, or a recurrence.
Hope to hear from you soon, happy to look into this for sure.
It was happening every time the network call was being send. We resolved it by looking up the customer_id on the frontend and added it to the request params under a new name, then read it on the otherside in the same way it would have read the empty param.
This is all taking place on the customer account page using the password login. The customer account pages (eg orders) show customer specific info, and we can get the customer details on the frontend.
We ended up going with a direct network call to our backend instead of going through the proxy There was a bigger issue that had no work around. To create the proxy url on the frontend could only be done with the stores original url (url shopify provides to the store when its created) but a store could have its own url, meaning the proxy failed. Would be awesome to have a way to handle this.
No worries at all @Barak_Setton, thanks for clarifying. Just want to make sure I’m understanding correctly, were you setting the shop’s proxy URL as the myshopify.com URL (more infoin the docs here) or as the public-url (for example myshop.com rather than myshop.shopify.com).
Our docs do mention that it should be set to myshopify.com, but I do also know we allow for multiple myshopify.com domains to be set in certain cases. Was this the “changed” myshopify.com domain you were using that was causing the issue and things only seemed to be resolved when you used the original myshopify.com domain?
Definitely happy to flag this to see if we can look into things further for you (or at the very least put at feature request through) - hope to hear from you soon!
Yes, the proxy call worked (besides the missing logged_in_customer_id value) when the primary url on the store was set to the default url (the one with xyz.myshopify.com) but if a store owner updated the primary url to something else (eg xyz.com) then the entire call did not work.
The store owner could go into the proxy setting on the app on the admin dashboard and customise the ‘App Proxy Url” to xyz.com, but it’s extra work every installer needs to do. Ideally it takes that into account out the box, or we could get access to the primary url when building the fetch function on the frontend (we only have access to the xyz.myshopify.com url)
Hopefully I’m understanding correctly here, but your current workaround of making direct backend calls instead of using the app proxy is totally valid. That’s a reasonable approach given the limitation.
If you did want to stick with the app proxy route, another option would be to fetch the shop’s primary domain via the Admin API (like the shop.primaryDomain field) when the app is installed, store it, and then use that stored value when constructing your proxy URLs on the frontend.
Let me know if you have any other questions, if the other option doesn’t work for you, let me know and I’d be happy to set up a feature request for you at the very least.
- this is a known issue with the App Proxy and logged_in_customer_id values. We are currently looking at is a possible bug, but I can’t guarantee an exact turnaround time for a fix.