Geschützte Downloads mit Supabase, Stripe, R2 und Cloudflare

Kostenpflichtige digitale Produkte brauchen ein langweiliges, aber wichtiges Fundament: Käufer sollten zahlen, sich anmelden und die richtige Datei herunterladen können, ohne einen öffentlichen ZIP-Link preiszugeben.

ImgKit verwendet ein einfaches Muster für geschützte Downloads:

1. Supabase übernimmt den Login.
2. Stripe übernimmt den Checkout.
3. Die Anwendung zeichnet den Produktzugriff auf.
4. R2 speichert private Dateien.
5. Cloudflare Functions geben kurzlebige signierte URLs zurück.

Warum geschützte Downloads wichtig sind

Wenn eine kostenpflichtige ZIP-Datei in einem öffentlichen Ordner liegt, kann jeder mit der URL sie teilen. Das mag für kostenlose Beispiele akzeptabel sein, aber es ist schwach für kostenpflichtige Produkte.

Geschützte Downloads fügen eine serverseitige Prüfung hinzu:

• Wer ist der Benutzer?
• Hat dieser Benutzer das Produkt gekauft?
• Ist das Download-Asset aktiv?
• Kann der Server eine temporäre URL erzeugen?

Der Benutzer erhält weiterhin einen normalen Browser-Download, aber der dauerhafte Speicherpfad ist nicht öffentlich.

Supabase-Login

Supabase gibt ImgKit eine Kontoidentität. Ein Käufer meldet sich mit E-Mail an, und dann können Checkout und Downloads an dieses Konto gebunden werden.

Für frühe Produkte reicht die E-Mail-Anmeldung. Käufer brauchen kein kompliziertes Dashboard, nur um eine geschützte Datei herunterzuladen.

Stripe-Checkout

Stripe übernimmt die Zahlungssitzung. Der Käufer startet den Checkout auf der Seite, zahlt und kehrt zu ImgKit zurück.

Der Server muss dann die abgeschlossene Sitzung mit dem Produktzugriff verbinden. Das kann über Webhooks und einen Checkout-Sync-Endpunkt geschehen, damit der Käufer den Zugriff bald nach der Zahlung sieht.

Produktzugriff

Produktzugriff sollte von allgemeinen Mitgliedschaftsbezeichnungen getrennt sein. Ein Käufer kann ein Produkt besitzen, aber nicht ein anderes.

Bei ImgKit nutzte der eingestellte Builder Case Study sein eigenes Produktrecht. Dieses Modell lässt künftige Produkte weiterhin existieren, ohne jeden Käufer zu einem breiten Abo-Mitglied zu machen.

Privater R2-Speicher

R2 speichert das eigentliche ZIP-Paket außerhalb des öffentlichen Website-Bundles. Die Seite verlinkt nicht direkt auf das R2-Objekt.

Stattdessen prüft ein Download-Endpunkt den Zugriff und fragt den Speicher nach einer temporären URL.

Signierte URLs

Eine signierte URL gewährt zeitlich begrenzten Zugriff auf eine private Datei. Wenn die URL nach einem kurzen Fenster abläuft, ist sie weniger nützlich für dauerhaftes Teilen.

Das ist kein schwergewichtiges DRM. Es ist eine praktische Grenze für kostenpflichtige Auslieferung in einem MVP.

Was ImgKit gelernt hat

Die archivierte Seite ImgKit Builder Case Study bewahrt die umliegenden Implementierungsentscheidungen: warum der Verkauf kostenpflichtiger Software pausiert wurde, wie geschützte Downloads geformt wurden und wie das Quellcodepaket als erstes kostenpflichtiges Angebot getestet wurde.

Dieser Kontext zählt, weil der technische Ablauf nur die Hälfte des Produkts ist. Die andere Hälfte ist zu entscheiden, was zuerst verkauft werden soll.

Häufige Fragen

Warum sollte man kostenpflichtige ZIP-Dateien nicht in einen öffentlichen Ordner legen?

Öffentliche Dateien können direkt geteilt werden. Geschützte Auslieferung lässt den Server den Kontozugriff prüfen und kurzlebige Download-URLs zurückgeben.

Speichert Stripe die Datei?

Nein. Stripe übernimmt die Zahlung. Produktzugriff und Download-Auslieferung werden von der Anwendung und dem privaten Speicher übernommen.

Warum signierte URLs verwenden?

Signierte URLs erlauben es, eine private Datei für begrenzte Zeit herunterzuladen, ohne dauerhaften Speicherzugriff preiszugeben.