Kamera-Vorschau im Browser: Zugriff erlauben ist noch kein Foto aufnehmen oder hochladen
Wenn eine Web-App ein Livebild der Kamera anzeigen soll, trennen Sie vier Schritte: Zugriff anfragen, Vorschau anzeigen, ein Bild bewusst übernehmen und dieses gegebenenfalls an den Server senden. Eine erteilte Kameraberechtigung erledigt nicht automatisch die übrigen Schritte. Ebenso muss feststehen, wann die Anwendung ihre laufenden Kamera-Tracks wieder beendet.
Eine solche Vorschau kann etwa beim Ausrichten eines Gegenstands vor einer Aufnahme helfen. Dieses Beispiel ist hypothetisch. Für das bloße Anhängen eines vorhandenen Fotos kann eine Dateiauswahl ausreichen; eine dauerhaft laufende Kameravorschau ist ein eigener Funktionsumfang.
Nur die tatsächlich benötigten Medien anfragen
MDN beschreibt getUserMedia() als Methode, die um Erlaubnis für einen Medieneingang bittet und bei Erfolg einen MediaStream liefert. Die angefragten Medientypen werden über video und audio festgelegt. Laut Dokumentation darf ein Typ mit dem Wert false nicht im resultierenden Stream enthalten sein.
Für eine reine Fotovorschau ist deshalb die Anforderung klar: Kamera ohne zusätzliches Mikrofon, sofern der vereinbarte Zweck keinen Ton benötigt. Übernehmen Sie nicht unbesehen ein Beispiel, das Bild und Ton gemeinsam anfragt. Der sichtbare Kameraknopf sollte erklären, weshalb die Funktion gebraucht wird, bevor die Person mit einer Systemabfrage konfrontiert ist.
Ein erfolgreicher Zugriff bedeutet zunächst, dass ein Stream vorliegt. Ob daraus ein Einzelbild erstellt, lokal zwischengespeichert, übertragen oder verworfen wird, muss die Anwendung gesondert umsetzen. Diese Schritte brauchen verständliche Namen statt eines allgemeinen Zustands „Fertig“.
Die echte Einbettung gehört zum Test
Die Dokumentation beschränkt getUserMedia() auf sichere Kontexte. Für eine öffentlich gehostete Anwendung gehört insbesondere die tatsächliche HTTPS-Auslieferung in den Prüfplan. Bei Einbettungen können zusätzlich die Vorgaben der übergeordneten Seite und deren Permissions Policy entscheiden, ob ein Frame überhaupt eine Anfrage stellen darf.
Ein Test auf dem Rechner des Entwicklers beweist daher nicht, dass dieselbe Vorschau im später eingebetteten Kundenportal funktioniert. Legen Sie fest, auf welchen Browsern und Geräten sowie in welcher Einbettung die Funktion unterstützt wird.
Falls die Kamera im vorgesehenen Kontext nicht verfügbar ist, braucht es eine ehrliche Erklärung. Eine alternative Dateiauswahl kann vereinbart werden, ist aber keine automatische Eigenschaft der Kamera-API. Entscheiden Sie, ob der übrige Vorgang ohne Aufnahme weitergeführt werden kann.
Ablehnen und Nichtentscheiden sind verschiedene Fälle
MDN nennt unter anderem verweigerte Berechtigung und fehlende passende Medien als mögliche Fehler. Die Dokumentation weist außerdem darauf hin, dass eine Person die Anfrage unbeantwortet lassen kann: Das zurückgegebene Promise muss dann weder erfolgreich abgeschlossen noch abgelehnt werden.
Für Ihre Oberfläche heißt das: Ein offener Dialog ist kein Beweis für einen Defekt und darf nicht nach kurzer Wartezeit als „Kamera freigegeben“ gelten. Bieten Sie einen Weg zurück zum Formular und erklären Sie, dass die Vorschau noch nicht bereit ist.
Planen Sie auch den späteren Erfolg einer alten Anfrage. Wenn die Person den Aufnahmebereich inzwischen verlassen hat und dann doch zustimmt, darf nicht überraschend eine überholte Vorschau weiterlaufen. Verlangen Sie, dass die Implementierung nicht mehr benötigte Streams erkennt und ihre Tracks freigibt. Das ist eine Anforderung an den Ablauf, kein in der Dokumentation zugesagter automatischer Abbruch.
Vorschau schließen heißt Tracks beenden
MDN beschreibt MediaStreamTrack.stop() als das Beenden eines Tracks. Sein Beispiel beendet jeden Track des Streams und löst anschließend die Verknüpfung mit dem Videoelement. Nur den sichtbaren Vorschaubereich zu verstecken ist keine gleichwertige technische Anforderung.
Benennen Sie die Ausstiegspunkte: Aufnahme abbrechen, zu einem anderen Auftrag wechseln, den Bereich schließen und den Vorgang beenden. Für jeden muss feststehen, ob noch ein legitimer Grund besteht, die Kameranutzung fortzusetzen. Andernfalls soll die Anwendung ihre zugehörigen Tracks beenden.
Versprechen Sie dabei nicht, dass das Stoppen eines einzelnen Tracks jede Kameranutzung des Geräts beendet. Laut MDN können mehrere Tracks dieselbe Quelle nutzen; die Quelle selbst muss deshalb nicht unmittelbar stoppen, solange sie noch anderweitig verwendet wird. Prüfen Sie die eigenen Tracks und verwechseln Sie die Freigabe durch Ihre App nicht mit einem globalen Ausschalter für alle Anwendungen.
Aufnahme und Übertragung bewusst bestätigen
Zeigen Sie nach einer Einzelaufnahme das tatsächlich ausgewählte Bild, bevor eine sensible Übertragung ausgelöst wird. Legen Sie fest, ob Neuaufnehmen das vorherige Bild ersetzt und ob Abbrechen bereits zwischengespeicherte Bilder verwirft. Diese Entscheidungen sind praktische Empfehlungen für Ihren Auftrag, keine von getUserMedia() vorgegebene Speicherpolitik.
Behaupten Sie nicht ohne Prüfung, eine Vorschau sei „nur lokal“. Die API-Beschreibung allein legt nicht fest, was die konkrete Anwendung mit den Daten tut. Der Entwickler muss den tatsächlichen Datenfluss erklären und die behaupteten Grenzen nachweisen.
Die serverseitige Annahme einer Datei bleibt anschließend eine andere Frage. Größenlimits, Dateiprüfung, Zugriffsrechte und Aufbewahrung gehören in die Upload-Spezifikation und werden durch Kameraberechtigung nicht erledigt.
Was Sie sich vorführen lassen sollten
Nutzen Sie einen nicht vertraulichen Testgegenstand und eine ausdrücklich freigegebene Testumgebung. Lassen Sie sich den reinen Kameraabruf ohne Mikrofon, die Vorschau und die bewusste Bildübernahme zeigen. Prüfen Sie auch die spätere Übertragung getrennt, sofern sie zum Projekt gehört.
Wiederholen Sie den Ablauf mit verweigertem Zugriff, einer zunächst unbeantworteten Anfrage und einem Wechsel aus dem Aufnahmebereich vor der Antwort. Kontrollieren Sie beim Abbrechen die eigenen Tracks und den sichtbaren Zustand, nicht nur, ob das Vorschaubild verschwunden ist.
Halten Sie Geräte, Browser, Einbettung und tatsächliche Ergebnisse fest. Dieser Artikel beschreibt Abnahmeanforderungen; er behauptet keine durchgeführten Kamera- oder Datenschutztests.
Brauche ich für ein Foto auch Mikrofonzugriff?
Nicht allein deshalb, weil die Kamera verwendet wird. Die dokumentierten Medientypen lassen sich getrennt anfragen. Beauftragen Sie nur, was der konkrete Zweck erfordert.
Ist das Anzeigen der Vorschau schon ein Upload?
Die dokumentierte Methode liefert einen Medienstream. Wie Ihre Anwendung daraus Bilder erzeugt oder Daten überträgt, ist eine gesonderte Implementierung. Lassen Sie diesen Datenfluss ausdrücklich erklären und prüfen.
Schaltet ein geschlossener Vorschaubereich sicher jede Kamera aus?
Nein. Verlangen Sie das Beenden der eigenen nicht mehr benötigten Tracks. Andere Tracks können dieselbe Quelle weiterhin verwenden; das dokumentierte Stoppen eines Tracks ist kein globales Geräteversprechen.
Halten Sie die unterstützte Umgebung und Ausstiegspunkte in den Akzeptanzkriterien fest. Die passende Abgrenzung zwischen Dateiauswahl und eigener Kamerafunktion lässt sich bei der Web-App-Entwicklung klären.