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?
- 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.