Shopify

Prüfplan — Shopify-Seite

Was hier steht, liess sich ohne einen echten Shopify-Shop nicht klären. Alles, was sich an der Dokumentation klären liess, ist aus dieser Liste entfernt und steht am Ende unter «Was bereits belegt ist» — damit niemand dieselbe Arbeit zweimal macht.

Sortiert nach Risiko: Wer oben abbricht, braucht unten nicht weiterzulesen.

Es geht durchgehend um den Shop-seitigen Teil: shopify.app.toml, Theme App Extension, Validation Function. Der Server (App Proxy, Webhook, Admin-API-Aufrufe) hat seinen eigenen Plan.

Zur Altersgrenze steht hier nichts zu prüfen — und das ist der Befund. Die Schnittstelle kann gegen 16 oder gegen 18 prüfen, und die anderen drei Pakete stellen das je Warengruppe ein. Dieses Paket nicht: Shopifys Warengruppe ist die Sammlung, und der App-Block kennt genau eine. Es gilt deshalb eine Grenze für alles, und sie kommt aus der Vorgabe des EdelVerify-Kontos — dieselbe, gegen die der App-Proxy den Nachweis wieder einlöst.

Der Block schickt bewusst kein min_age mit. Täte er es, könnte die Grenze im Theme von der Vorgabe abweichen: Der Laden startete eine 16er-Prüfung, der Server verlangte 18, und die Kundschaft sähe ein grünes Prüffenster und danach eine abgewiesene Rückmeldung. Nachgeprüft wird das statisch: python3 scripts/pakete-pruefen.py, Abschnitt K — «setzt die Grenze nirgends selbst».

Die Einschränkung steht ausführlich in EINBAU.md, Abschnitt 0. Sie gehört ins Verkaufsgespräch, nicht in eine Fussnote nach der Installation.

Es gibt keinen Installationsweg — und auch das ist ein Befund, kein Prüfpunkt. Der OAuth-Weg ist nicht gebaut: Die Rückrufadressen, die Shopify nach der Zustimmung anspringen würde, antworten auf verify.edelbyte.ch mit 404 (gemessen für /auth/callback und /auth/shopify/callback). Ein eingebetteter App-Bereich im Shopify-Admin ist ebenfalls ausgeschlossen: Die Seiten liefern X-Frame-Options: DENY und frame-ancestors 'none', ein Rahmen kann dort also nie rendern.

Solange das so ist, legt EdelByte jeden Shop von Hand an, und alle Einstellungen aus EINBAU.md, Schritt 4, nehmen wir vor. Für diesen Prüfplan heisst das: Die Prüfungen unten setzen einen bereits von Hand angelegten Entwicklungsshop voraus — sie prüfen den Shop-seitigen Teil, nicht die Installation. Wer den OAuth-Weg baut, braucht dafür einen eigenen Plan; die Prüfungen hier decken ihn nicht ab.

0. Umgebung

npm install -g @shopify/cli@latest
shopify version

# Im Ordner der App:
shopify app config link          # verbindet mit der App im Dev Dashboard
shopify app dev --store=<dev-store>.myshopify.com

Ausserdem gebraucht:

• ein Entwicklungsshop mit einem Online-Store-2.0-Theme (Dawn genügt) und einer Sammlung, die im Vertriebskanal «Online Store» verfügbar ist
• ein EdelVerify-Testkonto mit pk_test_… / sk_test_…; die Domain des Entwicklungsshops muss dort als erlaubte Herkunft eingetragen sein, sonst scheitert Prüfung 6 und man sucht den Fehler im falschen System
• ein Android-Handy mit der EdelVerify-App und einem Ausweis. Der E-ID-Weg ist abgeschaltet (EID_WEG_AKTIV, Vorgabe aus) — geprüft wird der Ausweis, und es gibt keinen Wahlschirm davor.
• für Weg B: ein Shop mit Shopify Plus. Ein gewöhnlicher Entwicklungsshop genügt nicht — Functions in Custom-Apps sind Plus vorbehalten. Ob ein Partner-Development-Store die Plus-Merkmale mitbringt, ist selbst zu prüfen (Prüfung 9).
• eine Rust-Werkzeugkette samt Wasm-Ziel:

  curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  rustup target add wasm32-unknown-unknown

Auf dem Rechner, auf dem dieses Paket zuletzt bearbeitet wurde, war sie nicht vorhanden (cargo not found). Der Rust-Teil ist deshalb bis heute nie übersetzt worden — siehe Prüfung 3, und lesen Sie sie, bevor Sie sich auf die Function verlassen.

Hoch

1. Überlebt ein Warenkorb-Attribut mit führendem Unterstrich die Bestellung?

Die ganze Bindung des Nachweises an die Bestellung hängt daran. Belegt ist nur, dass doppelter Unterstrich das Attribut überall verschwinden lässt; über den einfachen sagt die Dokumentation nichts.

Erste Bauhandlung, vor allem anderen. Im Laden, in der Browserkonsole:

await fetch(window.Shopify.routes.root + 'cart/update.js', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    attributes: { _edelverify: 'mit-strich', edelverify: 'ohne-strich' },
  }),
}).then((r) => r.json())

Dann eine Testbestellung abschliessen und nachsehen:

# Nutzdaten des Webhooks (Server-Log) — Feld note_attributes
# und/oder über die Admin API:
shopify app function replay   # nein, hier nicht; stattdessen:

query {
  orders(first: 1, reverse: true) {
    nodes { name customAttributes { key value } }
  }
}

Erwartet: beide Schlüssel kommen an. Wenn nur `edelverify` ankommt: an drei Stellen umstellen und nirgends sonst — blocks/edelverify.liquid (ev_attribut), src/cart_validations_generate_run.graphql (attribute(key:)) und die Webhook-Auswertung im Server.

2. Sieht die Validation Function dasselbe Attribut? *(nur mit Plus)*

Auch wenn das Attribut in der Bestellung ankommt, ist damit nicht gesagt, dass cart.attribute(key: "_edelverify") in der Function-Eingabe etwas liefert.

shopify app function run          # mit einer eigenen Eingabe-JSON
shopify app function replay       # mit einer echten Ausführung aus dem Shop

Erwartet: In der Eingabe der abgespielten Ausführung steht "attribute": { "value": "…" }. Steht dort null, obwohl das Attribut im Warenkorb liegt, ist die Function auf Plus wirkungslos — dann bleibt nur der Webhook, und das gehört dem Kunden gesagt.

3. Übersetzt die Function überhaupt?

Der Rust-Teil ist ein Gerüst. Die erzeugten Typpfade (schema::cart_validations_generate_run::input::cart::lines::Merchandise) und die Rückgabearten der Zugriffsmethoden (&String gegen &str, &bool gegen bool) stammen aus der Dokumentation, nicht aus einem Übersetzungslauf.

cd extensions/edelverify-gate
shopify app function schema          # holt schema.graphql
rustup target add wasm32-unknown-unknown
cargo build --target=wasm32-unknown-unknown --release
cargo doc --open                     # zeigt die tatsächlich erzeugten Typen
ls -l target/wasm32-unknown-unknown/release/edelverify_gate.wasm

Erwartet: Übersetzung ohne Fehler, Datei unter 256 kB. Weicht ein Typpfad ab, steht die richtige Schreibweise in cargo doc; die Logik bleibt davon unberührt.

Stand: nie ausgeführt. Zwei Gründe, beide handfest:

1. Auf dem Rechner, auf dem dieses Paket gepflegt wird, gibt es kein cargo.
2. schema.graphql liegt nicht im Paket und kann dort auch nicht liegen: Sie wird mit shopify app function schema geholt und setzt ein angemeldetes Partnerkonto samt verbundener App voraus. Ohne sie schlägt schon #[typegen("schema.graphql")] in main.rs fehl — und damit auch `cargo test, obwohl die Tests in cart_validations_generate_run.rs` keinen einzigen Shopify-Typ anfassen.

Was daraus folgt: Der erste Bau auf einem eingerichteten Rechner ist keine Formsache, sondern die erste echte Prüfung dieses Codes. Die naheliegenden Fundstellen sind die Zugriffsmethoden der Aliase (kollektion16(), schlagwort18() — typegen leitet sie aus der Eingabeabfrage ab) und die Rückgabearten (&bool gegen bool).

cargo test ist danach der zweite Schritt und der wichtigere: Die Entscheidungstabelle in mod tests ist die einzige Stelle, an der die Regel «18 schlägt 16» im Rust überhaupt zugesichert ist.

Ebenfalls hier zu klären: ob die erzeugte Wasm-Datei bei einem Paketnamen mit Unterstrich tatsächlich edelverify_gate.wasm heisst — der Pfad in shopify.extension.toml muss stimmen, sonst schlägt der Deploy fehl.

4. Der Cart-Token in der Rückmeldeadresse

Unser Skript hängt den Token aus GET /cart.js als ?ct= an die Proxy-Adresse. Zwei Fragen auf einmal:

1. Reicht der App Proxy eigene Abfrageparameter durch und nimmt sie in die Signatur auf? (Das Beispiel in der Dokumentation zeigt extra=1&extra=2 — aber unser Wert enthält selbst ein ?key=…, also kodierte Sonderzeichen.)
2. Ist der Wert derselbe wie cart_token in den Nutzdaten von orders/create, oder nur der Teil vor ?key=?

Handgriff: Im Laden eine Prüfung durchführen, im Server-Log die ankommende URL und den berechneten Signaturvergleich mitschreiben; danach die Bestellung abschliessen und cart_token aus dem Webhook danebenlegen.

Erwartet: Signatur stimmt, und die beiden Token lassen sich aufeinander abbilden. Wenn nicht, wird serverseitig auf den Teil vor ?key= normalisiert — an einer Stelle, nicht an zweien.

5. Wird `gate.js` von einer Content-Security-Policy geblockt?

Das Skript lädt https://verify.edelbyte.ch/v1/gate.js dynamisch nach. Setzt das Theme (oder eine andere App) eine CSP mit script-src, ohne unsere Domain zu nennen, passiert nichts — und zwar lautlos ausser einer Meldung in der Konsole.

Handgriff: Warenkorbseite öffnen, Konsole beobachten, dann auf «Alter bestätigen» klicken.

Erwartet: Das Skript lädt, window.EdelVerify existiert, das Fenster geht auf. Bei einer CSP-Meldung: mit dem Theme-Anbieter klären, ob verify.edelbyte.ch in script-src und connect-src aufgenommen werden kann.

Mittel

6. Die Prüfung von Anfang bis Ende, mit echtem Ausweis

• [ ] Streifen erscheint, sobald ein Artikel der Sammlung im Warenkorb liegt
• [ ] Auf der Warenkorbseite legt sich die Ebene darüber; Escape schliesst sie
• [ ] «Alter bestätigen» öffnet das Fenster von gate.js, QR erscheint
• [ ] In der EdelVerify-App den Ausweis lesen lassen → Fenster wird grün
• [ ] Im Netzwerk-Tab: POST /apps/edelverify/confirm?ct=… antwortet 200 {"ok":true} vor dem Neuladen
• [ ] Danach POST /cart/update.js mit dem Attribut, dann Neuladen (~0,9 s)
• [ ] Nach dem Neuladen: kein Streifen mehr, Kassenknöpfe frei

Die Reihenfolge der letzten drei Punkte ist der Test. Lädt die Seite neu, bevor /confirm geantwortet hat, wird die Übermittlung abgebrochen und der Nachweis ist verbrannt — er wird genau einmal ausgeliefert. Deshalb hängt das Neuladen an edelverify:stored, nicht an edelverify:verified.

Danach ins Server-Log sehen: weder `sk_…` noch `av_…` darf dort auftauchen.

7. Überschreibt `cart/update.js` fremde Attribute?

Manche Themes und Apps schreiben selbst Warenkorb-Attribute. Ob unser Aufruf nur den eigenen Schlüssel setzt oder die übrigen mitnimmt, ist zu messen — sonst löschen wir einem anderen etwas weg (oder umgekehrt, und unser Nachweis verschwindet beim nächsten Klick des Themes).

await fetch(window.Shopify.routes.root + 'cart/update.js', {
  method: 'POST', headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ attributes: { fremd: 'bleibt?' } }),
}).then(r => r.json())
// dann unser Attribut setzen und erneut GET /cart.js lesen

Erwartet: fremd steht danach noch da.

8. Kassenknöpfe in echten Themes

Die Auswahl [name="checkout"], .shopify-payment-button__button, form[action*="/checkout"] [type="submit"] deckt Dawn ab. Ein gekauftes Theme kann andere Knöpfe haben, vor allem in der Warenkorb-Schublade.

• [ ] Dawn: Warenkorbseite und Schublade
• [ ] Das Theme des Kunden, beide Orte
• [ ] Nach dem Öffnen/Schliessen der Schublade greift die Sperre weiterhin (Beobachter)
• [ ] Express-Checkouts (Shop Pay, Apple Pay, Google Pay) gehen daran vorbei — das ist erwartet und ohne Plus nicht zu ändern. Trotzdem einmal ansehen, damit es niemanden überrascht.

9. Läuft die Function auf dem Zielsystem überhaupt? *(nur mit Plus)*

Zu klären, bevor irgendetwas zugesagt wird:

• Tarif je Shop des Kunden (nur Plus kann Custom-Apps mit Functions)
• ob die Shops in einer Plus-Organisation liegen (entscheidet, ob eine Installation genügt)
• ob ein Partner-Development-Store die Function annimmt (zum Entwickeln)

shopify app deploy
# danach im Admin: Einstellungen → Checkout → Validierungen

Erwartet: Die Validierung erscheint und lässt sich einschalten. Kommt eine Tarifmeldung, ist Weg B für diesen Shop erledigt — dann gilt Weg A, und das gehört ins Kundengespräch, nicht in ein Ticket.

10. Instruktionsbudget

Erst messen, dann die Härtung aus Bauvorgabe 6.5 (signiertes Attribut mit HMAC-SHA256) zusagen.

shopify app function replay

Erwartet: Die einfache Fassung liegt weit unter den Referenzbeispielen (17 177 bzw. 19 272 Instruktionen für vergleichbare Prüfungen). Erst wenn HMAC-SHA256 dazukommt, wird es eng — dann hier nachmessen, nicht schätzen.

11. Der Umfang der Function

Die Collection-IDs stehen als Literal in der Eingabeabfrage und werden beim Deploy eingesetzt; das Metafeld edelverify/config entscheidet nur zwischen «ganzer Shop» und «nur diese Collection».

• [ ] Metafeld gesetzt (metafieldsSet auf die Validation) → Function sieht den Wert in der Eingabe
• [ ] Metafeld nicht gesetzt → jeder Warenkorb gilt als altersbeschränkt (gewollt: fail-closed), und der Händler merkt es sofort
• [ ] Platzhalter COLLECTION_ID_EINSETZEN nicht ersetzt → dieselbe Wirkung wie ohne Metafeld, nie eine stille Freigabe

Niedrig

12. Theme-Editor: Block, Einstellungen, Übersetzungen

• [ ] Altersprüfung (EdelVerify) erscheint unter Theme-Einstellungen → App-Einbettungen
• [ ] Alle sechs Einstellungen sind da, mit deutschen Beschriftungen — steht dort roher Text wie t:settings.public_key.label, findet Shopify die Schema-Sprachdateien nicht
• [ ] Der Direktlink zum Einschalten funktioniert: https://<shop>.myshopify.com/admin/themes/current/editor?context=apps&template=index&activateAppId=<client_id>/edelverify (der letzte Teil ist der Dateiname des Blocks, nicht der Name der Extension)
• [ ] Im Editor erscheint der Streifen, ohne dass etwas gesperrt wird (Shopify.designMode)

13. Sprachwahl im Laden

• [ ] Ein deutschsprachiger Laden zeigt die Texte aus de.json
• [ ] fr / it ebenso
• [ ] Eine nicht abgedeckte Sprache fällt auf en.default.json zurück und zeigt Englisch — keine leeren Streifen, keine Schlüsselnamen

Offen ist dabei, ob eine Theme App Extension zwingend en.default.json als Vorgabedatei verlangt oder auch de.default.json annähme. Deshalb liegt Englisch als Vorgabe bei; das ist die risikoärmere Wahl, nicht die schönste.

14. Auswahlfeld statt Handle

Die Sammlung wird heute als Text (Handle) eingetragen. Schöner wäre ein Auswahlfeld ("type": "collection"). Belegt ist nur, dass Resource-Settings in App blocks existieren; für App embed blocks sagt die Dokumentation nichts, und sie können ausdrücklich nicht auf dynamische Quellen zeigen.

Handgriff: In einer Wegwerf-Fassung des Blocks "type": "collection" setzen, shopify app deploy, im Editor nachsehen. Wird das Feld angeboten und liefert block.settings.collection.handle einen Wert, wird umgestellt — das spart die häufigste Fehleingabe (Titel statt Handle).

15. Warenkorb-Schublade und `request.page_type`

Die sperrende Ebene erscheint nur, wenn request.page_type == 'cart'. Themes mit Schublade führen den Kunden nie auf diese Seite.

• [ ] In einem Schubladen-Theme: Klick auf «Zur Kasse» in der Schublade wird abgefangen und öffnet die Prüfung direkt
• [ ] Nach dem Abbrechen bleibt der Kunde in der Schublade, nichts hängt

16. Grössengrenzen bei Deploy

shopify app deploy

Shopify prüft die Extension beim Deploy: alle Dateien zusammen ≤ 10 MB, höchstens 30 Blöcke, Liquid über alle Dateien ≤ 100 kB, je Sprachdatei ≤ 15 kB. Für JavaScript und CSS gelten 10 kB bzw. 100 kB als Empfehlung, nicht als harte Grenze. Unsere Dateien liegen deutlich darunter — nachsehen lohnt erst, wenn jemand etwas hinzufügt.

17. Legt der Server die Validation wirklich an? *(App-Store-Fassung)*

Der Schritt, der bis zum 6. September 2026 gar nicht gebaut war: Die Extension beschrieb in ihren Kommentaren zwei Metafelder, die unser Server schreibe — den Code dazu gab es nicht. Die Function war installiert und wirkungslos.

# In der eingebetteten App einmal speichern, danach im Admin:
#   Einstellungen → Checkout → Validierungen
# Erwartet: «EdelVerify Altersprüfung», eingeschaltet.
#
# Und über die Admin-API:
query { validations(first: 10) { nodes {
  id enabled blockOnFailure
  config: metafield(key: "config") { jsonValue }
  variablen: metafield(namespace: "$app:edelverify", key: "variables") { jsonValue }
} } }

Erwartet: enabled: true, blockOnFailure: true, beide Metafelder gefüllt, variables mit allen vier Schlüsseln — auch den leeren.

Zu messen ist ausserdem, ob $app:edelverify als Namensraum eines Input-Variablen-Metafelds von Shopify wirklich angenommen wird. Wird es das nicht, meldet Shopify InvalidVariableValueError beim Function-Lauf, und die Function fällt auf «ganzer Shop, ab 18» zurück — sie sperrt dann zu viel, nicht zu wenig, aber der Händler merkt es an der falschen Stelle.

18. Trennt die Kasse Bier von Spirituosen?

# Sammlung «Bier» auf ab 16, Sammlung «Spirituosen» auf ab 18.
# 1. Nur Bier im Warenkorb, angemeldeter Kunde mit Nachweis ab 16
#    → Kasse lässt durch.
# 2. Flasche Whisky dazulegen
#    → Kasse verweigert mit «… über 18 …».

Erwartet: Punkt 2 verweigert. Verweigert er nicht, ist die Reihenfolge in grenze_der_zeile verdreht — und dann liesse sich jede 18er-Ware mit einem zusätzlichen 16er-Eintrag entschärfen.

19. Wird ein angemeldeter Kunde wirklich dreissig Tage nicht neu gefragt?

# 1. Angemeldet prüfen, Bestellung abschliessen.
# 2. Abmelden, wieder anmelden, neuer Warenkorb.
# 3. Erwartet: kein Prüffenster, Kasse lässt durch.
# 4. Im Admin: Kunde → Metafelder → app-eigenes `verification`
#    Erwartet: {"v":1,"ab":[16,18],"bis":"JJJJ-MM-TT"}

Und die Gegenprobe, die wichtiger ist: Wird die Bestellung aus Schritt 3 vom orders/create-Webhook als geprüft gewertet? Sie trägt kein Warenkorb-Attribut. Wertet der Webhook sie als kein_attribut, hält er eine Bestellung an, die die Kasse eben durchgelassen hat — geprüft und trotzdem abgewiesen.

20. Fällt der `bis`-Tag um einen Tag zu früh oder zu spät?

Der Nachweis läuft auf die Minute ab, die Function kann nur Tage vergleichen. Hinterlegt wird deshalb der letzte Tag, der ganz in der Gültigkeit liegt.

# Prüfung um 08:00, Nachweis 30 Tage gültig.
# Erwartet im Metafeld: bis = Ablauftag MINUS EINS.

Ist es der Ablauftag selbst, trägt der Nachweis an diesem Tag bis Mitternacht — und zwar auch im Webhook, der dasselbe Feld liest.

Was bereits belegt ist

Diese Punkte standen zur Frage und sind an shopify.dev geklärt (Stand

1. August 2026). Sie gehören nicht mehr geprüft.