We are building a customer account extension with the UI component library @shopify/ui-extensions/customer-account.
The extension will authenticate the customer with the customer.id hashed with a secret key (here is our documentation). However, we do not want the secret key to be in the client-side code.
Is it possible to add liquid code in the customer account components?
Alternatively, can we do some server-side computing to generate our hash from the secret key and the customer.id ?
Thanks for describing your use-case and linking to your docs I don’t believe Liquid is supported on extensions for customer accounts (like it was on the older version of customer accounts), but I’ll doublecheck with that team. If not, I’ll see what their recommendation is for ensuring the secret key remains secure.
I have a couple questions to help us identify what the best approach would be:
1: When you say “the extension will authenticate the customer with the customer.id” - customers are either already authenticated when an extension loads, or can be redirected to the authentication page via the requireLogin API. Is this authentication a process that would be taking place on Garnets side?
2: Have you looked into using session tokens for storing data?
Also I have confirmed that it’s not possible to use/access Liquid objects from within customer extensions.
Our service needs to trust that the user was logged into Shopify, so we give Shopify a secret key that, combined with the customer.id, will prove that the user is authenticated on Shopify.
So yes, the authentication will take place on Garnet’s side.
These session tokens are used and signed with a secret key by Shopify.
We want to do something similar but with token signed with our secret key.
The feature we are looking for is to add liquid code (or any server-side processed code) to create this authentication token for our service.
I don’t believe Liquid is supported on extensions for customer accounts (like it was on the older version of customer accounts), but I’ll doublecheck with that team. If not, I’ll see what their recommendation is for ensuring the secret key remains secure.