Ratgeber

Datei-Uploads in deine App einbauen: Speicher, Limits und Sicherheit

Um Datei-Uploads in deine App einzubauen, speicherst du die Dateien im Objektspeicher (einem Bucket), nicht auf der Festplatte deines Servers oder in der Datenbank. In der Datenbank legst du einen kleinen Datensatz mit Schlüssel, Name, Größe, Typ und Besitzer der Datei ab. Größe und Typ prüfst du auf dem Server. Lege von Anfang an fest, ob Dateien öffentlich sind (etwa Produktfotos) oder privat (etwa Rechnungen), und liefere private Dateien erst aus, nachdem du geprüft hast, wer fragt. In einem KI-App-Builder beschreibst du die Upload-Funktion mit einem Prompt. Wichtig ist, dass du testest, ob Dateien ein Neu-Deployment überleben und nicht von der falschen Person geöffnet werden können.

Lege fest, welche Uploads du brauchst

Beantworte vor dem Bauen drei Fragen:

  1. Welche Dateien? Profilfotos, Produktbilder, PDFs, Tabellen, Audio, Video. Das bestimmt Typ- und Größenbeschränkungen.
  2. Wer darf sie sehen? Alle (eine öffentliche Galerie) oder nur der Hochladende und Admins (Verträge, Ausweisdokumente, Kundendateien).
  3. Was passiert nach dem Upload? Nur speichern, eine Vorschau zeigen, Bilder verkleinern oder den Inhalt auslesen.

Öffentliche Bilder und private Dokumente brauchen unterschiedliche Setups, deshalb kläre das zuerst.

Wo Dateien liegen sollten

OptionSo funktioniert esGut fürWorauf achten
Objektspeicher (Bucket)Dateien liegen in einem Dienst dafür; deine Datenbank speichert einen Schlüssel oder eine URLFast jede AppZugriffsregeln müssen richtig gesetzt sein
Vom Plattformanbieter bereitgestellter SpeicherDein App-Builder oder Hoster aktiviert einen Bucket für dichApps auf dieser PlattformLimits und Preise folgen der Plattform
Server-FestplatteDateien werden im Dateisystem des App-Servers geschriebenNur lokale EntwicklungWird beim Neustart oder Neu-Deployment oft gelöscht
In der DatenbankDie Dateibytes liegen in einer TabelleFast nieBlähen die Datenbank auf und verlangsamen Backups
Drittanbieter-Upload-WidgetEin gehosteter Uploader übernimmt den gesamten AblaufSchwere Medien, BildtransformationenEin weiterer Anbieter, Konto und Rechnung

Für die meisten Apps ist Objektspeicher plus ein Datensatz in der Datenbank die richtige Antwort. Die Datenbankzeile ist das, was deine App abfragt („zeige die Dokumente dieses Nutzers“); der Bucket hält nur die Bytes.

Öffentliche vs. private Dateien

  • Öffentliche Dateien (Produktfotos, Blogbilder, Avatare) können über eine öffentliche URL ausgeliefert werden. Jeder mit dem Link kann sie öffnen, was bei dieser Art Inhalt in Ordnung ist.
  • Private Dateien (Rechnungen, Verträge, medizinische oder Ausweisdokumente, Kundenlieferungen) dürfen nie eine erratbare öffentliche URL haben. Der Server prüft, ob der angemeldete Nutzer die Datei besitzt oder berechtigt ist, und liefert sie dann entweder selbst aus oder gibt eine signierte URL zurück: einen Link, der nur für kurze Zeit funktioniert.

Ein häufiger und ernster Fehler sind private Dateien in einem öffentlichen Bucket mit vorhersagbaren Namen. Wer /uploads/invoice-102.pdf errät, bekommt die Rechnung eines anderen.

Beispiel-Prompts

Ein öffentlicher Bild-Upload:

Lass Admins bis zu 5 Produktfotos pro Produkt hochladen. Akzeptiere JPG, PNG und WebP bis jeweils 5 MB. Speichere die Dateien im Dateispeicher, lege Schlüssel, Größe und Reihenfolge jedes Bildes in einer Tabelle product_images ab und zeige Vorschaubilder mit einem Entfernen-Button. Prüfe Typ und Größe auf dem Server, nicht nur im Browser.

Ein privater Dokumenten-Upload:

Füge eine Dokumentseite für angemeldete Kunden hinzu. Kunden können PDFs bis 20 MB hochladen. Die Dateien sind privat: Speichere sie im Dateispeicher und lege Besitzer-ID, ursprünglichen Dateinamen, Größe und Upload-Zeitpunkt in einer Tabelle documents ab. Nur der Besitzer und Admins dürfen herunterladen. Downloads laufen über eine Server-Route, die die Berechtigung prüft. Gib für diese Dateien nie eine öffentliche URL heraus.

Nützliche Ergänzungen:

Zeige während des Uploads einen Fortschrittsbalken und eine klare Fehlermeldung, wenn die Datei zu groß ist oder der falsche Typ.

Wenn ein Dokument-Datensatz gelöscht wird, lösche auch die gespeicherte Datei.

Schritt für Schritt

  1. Lege Typen und Größenlimits für jedes Upload-Feld fest. Sei konkret: „PDF bis 20 MB“, nicht „Dokumente“.
  2. Aktiviere den Speicher. In einem KI-Builder fragst du nach Uploads, und er richtet den Speicher ein; anderswo legst du einen Bucket an und hinterlegst seine Zugangsdaten als Geheimnisse auf dem Server.
  3. Erstelle eine Datenbanktabelle für die Dateidatensätze: ID, Besitzer, Speicherschlüssel, ursprünglicher Name, Typ, Größe, Erstellzeitpunkt.
  4. Baue die Upload-Route auf dem Server: Prüfe, ob der Nutzer angemeldet ist, prüfe Typ und Größe, erzeuge einen sicheren Speicherschlüssel (nicht den Dateinamen des Nutzers), speichere die Datei und füge den Datensatz ein.
  5. Baue den Download- oder Anzeigeweg: öffentliche URL für öffentliche Dateien; eine Route mit Berechtigungsprüfung oder eine signierte URL für private.
  6. Baue die Oberfläche: Dateiauswahl, bei Bedarf Drag-and-drop, Fortschritt, Vorschauen, Fehler.
  7. Kümmere dich um das Löschen, sodass das Entfernen eines Datensatzes auch die gespeicherte Datei entfernt.
  8. Teste: hochladen, neu laden, neu deployen oder veröffentlichen und prüfen, ob die Datei noch lädt. Melde dich dann als anderer Nutzer an und versuche, die privaten Dateien des ersten Nutzers zu öffnen.

Häufige Fehler

  • Uploads auf die Server-Festplatte schreiben. In der Entwicklung funktioniert es, dann verschwinden die Dateien nach einem Neustart oder Neu-Deployment.
  • Den Prüfungen im Browser vertrauen. Die Einstellung „accept“ eines Dateifelds ist ein Hinweis, keine Sicherheit. Prüfe Typ und Größe auf dem Server.
  • Den Dateinamen des Nutzers als Speicherschlüssel verwenden. Namen kollidieren und können seltsame Zeichen enthalten. Erzeuge einen eindeutigen Schlüssel und speichere den Originalnamen separat.
  • Öffentliche Buckets für private Dateien. Siehe oben; das ist der Fehler, der in die Nachrichten kommt.
  • Jeden Dateityp erlauben. HTML- oder SVG-Dateien, die von deiner Domain ausgeliefert werden, können in manchen Setups Skripte ausführen. Akzeptiere nur die Typen, die du brauchst.
  • Keine Größenbegrenzung. Ein riesiger Upload kann dein Speicherkontingent aufbrauchen oder die Anfrage ins Timeout laufen lassen.
  • Verwaiste Dateien. Wer den Datenbankeintrag löscht, aber nicht die Datei, füllt den bezahlten Speicher langsam auf.
  • Mobile Geräte vergessen. Handyfotos können groß sein und in Formaten wie HEIC vorliegen; entscheide, ob du sie akzeptierst oder umwandelst.

Checkliste

  • Dateien landen im Objektspeicher, nicht auf der Server-Festplatte oder in der Datenbank
  • Jede Datei hat einen Datensatz mit Besitzer, Schlüssel, Name, Typ und Größe
  • Typ und Größe werden auf dem Server geprüft
  • Speicherschlüssel werden erzeugt, nicht aus dem Dateinamen übernommen
  • Private Dateien werden erst nach einer Berechtigungsprüfung ausgeliefert
  • Ein anderer Nutzer kann deine privaten Dateien auch mit dem Link nicht öffnen
  • Das Löschen eines Datensatzes löscht die Datei
  • Dateien laden nach dem Veröffentlichen oder Neu-Deployen noch
  • Upload-Fehler werden klar angezeigt, auch auf dem Handy

Datei-Uploads in Mythex

Mythex kann für ein Projekt automatisch Dateispeicher aktivieren, wenn deine App Uploads braucht. Du musst also keinen Bucket von Hand bereitstellen. Du kannst auch /storage im Chat tippen. Der Speicher ist auf Free und Pro verfügbar, auf Free mit einer Obergrenze von 1 GB, und du siehst seinen Status unter Einstellungen → Speicher.

Die Dokumentation sagt deutlich, dass das veröffentlichte Hosting kein dauerhaftes lokales Dateisystem ist. Bitte den Agenten daher, Plattformspeicher zu nutzen, statt auf die Festplatte zu schreiben. Gespeicherte Dateien und Downloads werden aus deinem Credit-Guthaben bezahlt, nach Größe und danach, wie viel heruntergeladen wird; Pro zahlt die Hälfte des Free-Preises. Siehe Dateispeicher in der Dokumentation.

Uploads gehen meist mit einer Datenbank für die Dateidatensätze und einer Anmeldung für private Dateien einher. Wenn du einen Ort baust, an dem Kunden Dokumente austauschen, lies wie du ein Kundenportal baust, und geh vor dem Start die Sicherheits-Checkliste durch.

Fragen

Wo sollten hochgeladene Dateien gespeichert werden?

In einem Objektspeicher (einem Dienst für Dateien, oft Bucket genannt), nicht auf der Festplatte des App-Servers und nicht in der Datenbank. In deiner Datenbank speicherst du nur den Schlüssel oder die URL der Datei sowie Angaben wie Name, Größe und Besitzer.

Warum verschwinden meine hochgeladenen Dateien nach dem Veröffentlichen oder Neu-Deployen?

Die meisten Hosting-Plattformen haben keine dauerhafte lokale Festplatte: Wenn die App neu startet oder neu deployt wird, gehen Dateien verloren, die auf ihre Festplatte geschrieben wurden. Speichere Uploads stattdessen im Objektspeicher.

Wie halte ich hochgeladene Dateien privat?

Mach die Dateien nicht öffentlich lesbar. Dein Server prüft, ob der angemeldete Nutzer eine Datei sehen darf, und liefert sie dann aus oder gibt einen kurzlebigen signierten Link zurück.

Unterstützt Mythex Datei-Uploads?

Ja. Mythex kann für ein Projekt Dateispeicher aktivieren, wenn die App Uploads braucht, auf Free und Pro, auf Free mit einer Obergrenze von 1 GB. Du fragst den Agenten nach der Upload-Funktion oder tippst /storage.

Mythex · Pricing · Alles mit KI bauen · Vorlagen für Websites und Apps · Mythex im Vergleich · Glossar zum App-Bau mit KI · Kostenlose Tools für den App-Bau mit KI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)