Umgebungsvariablen und Sicherheit

Bevor wir den Integration-Token aus Kapitel 5 im Code verwenden, richten wir eine saubere Konfiguration ein – UND besprechen offen, wo die Grenzen dieses Ansatzes für ein Lern-Projekt liegen.

Umgebungsvariablen in Vite: das VITE_-Präfix

Vite liest Umgebungsvariablen aus einer .env-Datei im Projekt-Wurzelverzeichnis – aus SICHERHEITSGRÜNDEN aber NUR solche, die mit VITE_ beginnen. Alle anderen bleiben dem Server-seitigen Build-Prozess vorbehalten und landen NICHT im an den Browser ausgelieferten Code.

.env

VITE_MAGENTO_BASE_URL=https://IHR-SHOP.de/rest/V1
VITE_MAGENTO_ACCESS_TOKEN=IHR_INTEGRATION_ACCESS_TOKEN

.env.example

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

.env.example committen wir MIT ins Repository (ohne echte Werte) – das zeigt jedem, der das Projekt später auscheckt, WELCHE Variablen benötigt werden, ohne Geheimnisse preiszugeben.

.gitignore

node_modules/
dist/
.env

Achtung: .env MUSS in .gitignore stehen – sonst landet Ihr echter Access Token im Git-Verlauf, selbst wenn Sie ihn später wieder löschen (Git-Historie vergisst nichts, ohne aufwendige History-Bereinigung).

Die Variablen im Code lesen

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

import.meta.env ist Vites eingebauter Zugriff auf Umgebungsvariablen – GENAU dieses Muster nutzen wir in Kapitel 7 in api/magentoApi.js.

Die ungeschminkte Wahrheit: Tokens im Client-Code

Achtung: Auch mit .env und .gitignore gilt: Sobald Sie npm run build ausführen, landet der Access Token im FERTIGEN JavaScript-Bundle, das an JEDEN Browser ausgeliefert wird, der Ihre Seite öffnet. VITE_-Variablen sind NICHT geheim, sobald die App gebaut ist – sie verhindern nur, dass der Token im QUELLCODE-Repository landet, NICHT, dass er im öffentlich ausgelieferten Code sichtbar ist. Öffnen Sie nach einem Build einfach die Netzwerk-Anfragen im Browser: Der Token steht im Klartext im Authorization-Header.

Der richtige Weg für eine echte Produktions-App

In einer ECHTEN Anwendung würde ein eigenes Backend (z. B. ein kleiner Node.js/Express- oder Magento-eigener Endpunkt) als Vermittler dienen: Das Frontend spricht NUR mit diesem eigenen Backend, das Backend allein kennt den Magento-Token und reicht Anfragen serverseitig weiter. So bleibt der Token NIEMALS im an den Browser ausgelieferten Code sichtbar.

Tipp: Für DIESES Lern-Projekt ist der direkte Weg (Token im Frontend) bewusst gewählt, um sich auf die Magento-API-Integration selbst zu konzentrieren, ohne gleichzeitig ein zweites Backend-Projekt aufbauen zu müssen. Nutzen Sie diesen Ansatz NICHT unverändert für einen Shop mit echten Kundendaten oder Schreibzugriff (Bestellungen, Kundendaten) – für reines, öffentlich sichtbares LESEN von Produktdaten (wie in diesem Tutorial) ist das Risiko begrenzt, aber die Grenze sollten Sie bewusst kennen.

Dev-Server nach .env-Änderungen neu starten

Achtung: Vite liest .env-Dateien NUR beim Start des Dev-Servers ein – Änderungen an .env während npm run dev bereits läuft, werden NICHT automatisch übernommen. Beenden Sie den Server (Strg+C) und starten Sie ihn nach JEDER .env-Änderung neu.