Environment Variables and Security

Before using the integration token from chapter 5 in code, let's set up a clean configuration – AND talk openly about where this approach's limits lie for a learning project.

Environment variables in Vite: the VITE_ prefix

Vite reads environment variables from a .env file in the project root – but for SECURITY REASONS, only ones starting with VITE_. All others stay reserved for the server-side build process and do NOT end up in the code shipped to the browser.

.env

VITE_MAGENTO_BASE_URL=https://YOUR-SHOP.com/rest/V1
VITE_MAGENTO_ACCESS_TOKEN=YOUR_INTEGRATION_ACCESS_TOKEN

.env.example

VITE_MAGENTO_BASE_URL=https://your-shop.example/rest/V1
VITE_MAGENTO_ACCESS_TOKEN=your-access-token-here

We commit .env.example to the repository (with no real values) – it shows anyone checking out the project later WHICH variables are needed, without exposing any secrets.

.gitignore

node_modules/
dist/
.env

Achtung: .env MUST be in .gitignore – otherwise your real access token ends up in Git history, even if you delete it again later (Git history forgets nothing without a laborious history rewrite).

Reading the variables in code

const baseUrl = import.meta.env.VITE_MAGENTO_BASE_URL;
const accessToken = import.meta.env.VITE_MAGENTO_ACCESS_TOKEN;

import.meta.env is Vite's built-in access to environment variables – EXACTLY this pattern is what we use in chapter 7's api/magentoApi.js.

The unvarnished truth: tokens in client code

Achtung: Even with .env and .gitignore, this still holds: once you run npm run build, the access token ends up in the FINISHED JavaScript bundle shipped to EVERY browser that opens your page. VITE_ variables are NOT secret once the app is built – they only prevent the token from ending up in the SOURCE CODE repository, NOT from being visible in the publicly shipped code. After a build, just open the network requests in the browser: the token sits in plain text in the Authorization header.

The proper approach for a real production app

In a REAL application, a dedicated backend (e.g. a small Node.js/Express server or a Magento-side endpoint) would act as a mediator: the frontend talks ONLY to this own backend, and only the backend knows the Magento token and forwards requests server-side. That way the token is NEVER visible in code shipped to the browser.

Tipp: For THIS learning project, the direct approach (token in the frontend) is deliberately chosen to focus on the Magento API integration itself, without also having to build a second backend project at the same time. Do NOT use this approach unchanged for a shop with real customer data or write access (orders, customer data) – for plain, publicly visible READING of product data (as in this tutorial), the risk is limited, but you should know that boundary consciously.

Restarting the dev server after .env changes

Achtung: Vite only reads .env files when the dev server STARTS – changes to .env while npm run dev is already running are NOT picked up automatically. Stop the server (Ctrl+C) and restart it after EVERY .env change.