Regarding exposure of “PUBLIC_STOREFRONT_API_TOKEN”

[shota-f]

Question

Are there any required components or libraries in this project that use or expose “PUBLIC_STOREFRONT_API_TOKEN”(public access)?
Or is there a possibility that such code will be included in the future?

Why

I understand that most of the requests to storefront-api in this project will be made via server-side “PRIVATE_STOREFRONT_API_TOKEN”(private access).

I am asking this question because if it is promised that only “private access” will be used in the future, then it may be possible to bypass some of Shopify's limitations without having to install an app or upgrade a plan.

e.g. Uber eats toppings

We can add “more vegetables” or “garlic” to “ramen”, and the price is added accordingly.

uber-eats-toppings.mov

But to accomplish this in shopify, we are limited to the following options, even though we are a headless developer.

1. paid apps for product bundles
2. paid apps that use shopify-functions
3. upgrade to the Plus plan and create custom apps for the above

I don't expect it to get much better in the future, as these features are very much tied to the traditional “online store”.

So I want to focus on what we can do within the limitations of the platform.
e.g.) Avoiding limitations on the number of product options, variations https://www.youtube.com/watch?v=vOaeMvD1CK0

Solution

Going back to the “Uber eats toppings”, let's say we want to implement “additional products” through metafields and metaobjects.

The simplest way to do this would be to add a “product list type metafield” to the product.

If the store owner adds the options “more vegetables” and “garlic” to the meta field for ramen, the developer can simply include a UI that allows these toppings to be added.

If the store owner does not want to sell the toppings alone, the product page can simply return a 404.

Problem

But the problem is the cart.

If there is no code in the Hydrogen project to expose the “public access token” in a required component, library, etc., we can disallow the toppings-only request in the request to the cart.
We can also disallow the use of “public access” and ask the store owner to protect the token.

I believe that if we can “maximize the benefits of server-side development”, we will have a much wider range of development options.

Or is it more like “don't implement this, just add more apps or upgrade your plan”?

[shota-f]

Perhaps it is obvious, but I have confirmed that if “PUBLIC_STOREFRONT_API_TOKEN” is exposed, anyone can easily manipulate the cart using curl or other means.
Therefore, I found that the above approach could not be used.

The target cart ID can be easily retrieved from the cookie of the traditional online store and the store made by Hydrogen template.

Below is a forum about similar restrictions on the traditional online store.(in Japan)

https://community.shopify.com/c/%E6%8A%80%E8%A1%93%E7%9A%84%E3%81%AAq-a/%E5%88%A5%E3%80%85%E3%81%AE%E5%95%86%E5%93%81%E3%82%BF%E3%82%A4%E3%83%97%E3%81%AE%E5%95%86%E5%93%81%E3%82%92%E5%90%8C%E6%99%82%E3%81%AB%E8%B3%BC%E5%85%A5%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%AF%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99%E3%81%8B/td-p/1096832

This forum seems to have come to the conclusion that it is possible to limit product combinations by “not rendering the checkout link on the cart page”.

However, if the “PUBLIC_STOREFRONT_API_TOKEN” is exposed, it can be easily manipulated.

And the Hydrogen template exposes it to the browser via consent.storefrontAccessToken from the loader in app/root.tsx.