Doconut‑Viewer ist eine .NET-Bibliothek zum Anzeigen von Dokumenten, die entwickelt wurde, um PDF-, Office-, CAD-, Bild- und andere unterstützte Dokumentfamilien in eine Anwendung einzubetten. Eine solide Doconut-Integration dreht sich weniger darum, das kürzeste Snippet zu finden, sondern vielmehr darum, eine klare Grenze zwischen Ihrer Anwendung, dem Viewer und dem Browser zu wählen.

Eine eingebettete Dokumentvorschau, angeordnet innerhalb eines strukturierten Web‑Anwendungs‑Arbeitsbereichs

Der Doconut-Dokumentationszentrum verweist auf die gepflegten Setup‑Pfade für unterstützte .NET‑Projekttypen. Verwenden Sie die Anleitung, die zur in Ihrer Anwendung installierten Version passt, und behandeln Sie dann die umgebende Seite, Identitätsprüfungen und den Zugriffs‑Workflow als Anwendungscode, der Ihrem Team gehört.

Beginnen Sie mit der Integrationsgrenze

Es gibt drei gängige Methoden, um eine Dokumentvorschau in ein Produkt einzubetten. Die richtige Wahl hängt davon ab, wer Navigation, Authentifizierung und den Lebenszyklus des Viewers besitzt.

Muster	Beste Passung	Hauptkompromiss
Anwendungsansicht	Eine .NET‑Seite, die den Viewer neben den Produktsteuerelementen rendert	Enge Integration, aber Seite und Viewer‑Lebenszyklus sind gekoppelt
Anwendungs‑eigenes iframe	Ein Portal, das Isolation zwischen der Host‑UI und der Vorschau‑Route benötigt	Klare Grenze, aber Kommunikation muss explizit gestaltet werden
Framework‑Komponente um eine Server‑Route	Eine React‑, Angular‑ oder Vue‑Shell, unterstützt von einer .NET‑Anwendung	Vertraute Front‑End‑Komposition, mit mehr zu verwaltenden Lebenszyklus‑Zuständen

Das iframe‑Muster muss nicht auf eine öffentliche Dokument‑URL zeigen. Es kann auf eine authentifizierte Route in Ihrer eigenen Anwendung zeigen. Diese Route kann den Zugriff prüfen und die Viewer‑Seite rendern, ohne einen Speicherpfad für die Host‑Seite offenzulegen.

Erstellen Sie eine stabile, responsive Vorschaufläche

Rekonstruieren Sie nicht das Viewer‑Markup oder die Initialisierung aus einem illustrativen Blog‑Snippet. Doconut veröffentlicht die Dateien, Middleware‑Schritte, Namespaces und Viewer‑Setups, die zu jeder unterstützten .NET‑Version passen. Zum Beispiel erklärt der offizielle .NET 6‑ oder höher‑Setup‑Guide die Server‑Middleware, das Viewer‑Objekt, Dokument‑Optionen, Rendering‑Konfiguration und die erforderlichen Client‑Assets.

Verwenden Sie diese versionierten Materialien, um den Viewer zu erstellen, und geben Sie seiner Host‑Region in Ihrem Layout eine stabile Breite und Höhe. Reservieren Sie genug Platz, bevor das Laden beginnt, damit die umgebende Seite nicht springt, und testen Sie die Symbolleiste sowie die erste Seite an den tatsächlichen Breakpoints, die Ihr Produkt unterstützt.

Bevor Sie sich für eine Komposition entscheiden, vergleichen Sie sie mit den offiziellen Doconut-Live-Demos. Die Demos decken mehrere .NET‑ und Front‑End‑Integrationsstile ab, einschließlich eines dedizierten iframe‑Beispiels, und helfen, einen offiziell unterstützten Pfad von einem plausibel aussehenden Snippet zu unterscheiden.

Entscheidungen zum Zugriff auf dem Server behalten

Die Host‑Seite sollte niemals entscheiden, ob ein Benutzer ein Dokument ansehen darf. Bevor die Vorschau‑Route gerendert wird, sollte die Anwendung:

Die Anfrage authentifizieren.
Den Benutzer für das angeforderte Dokument und den Mandanten autorisieren.
Das Dokument über einen servergesteuerten Bezeichner auflösen.
Es nur nach erfolgreicher Prüfung über den Viewer öffnen.
Einen generischen „nicht gefunden“‑ oder „verboten“‑Zustand zurückgeben, ohne Speicher‑Details preiszugeben.

Ein undurchsichtiger Bezeichner verbessert die URL‑Hygiene, ist jedoch keine Autorisierung. Wenden Sie dieselben Prüfungen auf Seiten‑, Thumbnail‑, Such‑, Annotations‑, Export‑ und Druck‑Anfragen an, die Sie bereitstellen.

Wie Host und Viewer kommunizieren

Eine Anwendungsansicht kann ihre eigenen Komponenten direkt aufrufen. Ein iframe benötigt einen engeren Vertrag. Definieren Sie nur die Ereignisse, die der Host wirklich benötigt, z. B.:

Vorschau bereit
Dokument konnte nicht geöffnet werden
Aktuelle Seite geändert
Sitzung abgelaufen
Benutzer hat das Schließen der Vorschau angefordert

Wenn Sie postMessage verwenden, validieren Sie sowohl event.origin als auch die Nachrichtenstruktur. Akzeptieren Sie in der Produktion keine Wildcard‑Origins und übermitteln Sie niemals Anmeldeinformationen, Speicherorte oder Roh‑Dokumentinhalte über Nachrichten.

Browser‑Einschränkungen als Defense‑in‑Depth behandeln

Ein iframe ist nicht automatisch isoliert. Das Attribut sandbox kann Fähigkeiten reduzieren, aber ein zu strenger Wert kann auch Viewer‑Skripte, Downloads oder Same‑Origin‑Verhalten brechen. Beginnen Sie mit dem kleinsten, dokumentierten Fähigkeits‑Set für Ihre Integration und testen Sie es zusammen mit Ihrer Content‑Security‑Policy.

Berücksichtigen Sie außerdem:

frame-ancestors oder X-Frame-Options für die Vorschau‑Route
frame-src für die Host‑Seite
Same‑Site‑Cookie‑Verhalten, falls das iframe eine Sitzung benötigt
Referrer‑Policy für URLs, die Routing‑Bezeichner enthalten
Cache‑Header für Seiten, die sensible Inhalte anzeigen

Diese Kontrollen gehören zur umgebenden Anwendung und Infrastruktur. Eine Viewer‑Komponente kann nicht die richtige Richtlinie für Ihre Mandantschaft und Ihr Bedrohungsmodell wählen.

Gestaltung von Lade‑, Fehler‑ und Ablauf‑Zuständen

Ein leeres Rechteck ist keine hilfreiche Fehlermeldung. Geben Sie der Host‑Seite explizite Zustände für Autorisierungsfehler, nicht unterstützte Eingaben, beschädigte Dateien, Zeitüberschreitungen und abgelaufene Sitzungen. Formulieren Sie die Meldungen handlungsorientiert, ohne interne Pfade oder Ausnahme‑Details preiszugeben.

Bei langen Dokumenten behalten Sie den Viewer‑Container bei, während die erste Seite vorbereitet wird. Wenn Benutzer Dokumente wechseln können, ohne die Seite zu verlassen, brechen Sie veraltete Anfragen ab und setzen Sie Titel, Seitenzahl und Fokus zurück, bevor das nächste Element geladen wird.

Barrierefreiheit und Tastaturverhalten

Geben Sie jedem iframe ein sinnvolles title. Machen Sie die Vorschau per Tastatur erreichbar, bieten Sie einen sichtbaren Weg, den Fokus zurück zur Host‑Seite zu bringen, und verhindern Sie das „Fangen“ des Fokus in benutzerdefinierten Overlays. Wenn der Viewer eigene Tastatur‑Shortcuts hat, dokumentieren Sie Konflikte mit den Shortcuts Ihrer Produkt‑Shell.

Ein barrierefreier Fallback kann einen kontrollierten Download oder eine alternative Darstellung anbieten, wenn Ihre Geschäftsregeln dies zulassen. Fügen Sie keinen öffentlichen Dateilink nur als Fallback hinzu.

Praktische Prüfliste zur Verifizierung

Vor dem Release prüfen Sie den gesamten Anforderungspfad und nicht nur den initialen Seiten‑Load:

Ein autorisierter Benutzer kann ein erlaubtes Dokument öffnen.
Ein Benutzer eines anderen Mandanten kann die Vorschau‑URL nicht wiederverwenden.
Direkte Anfragen an viewer‑bezogene Endpunkte erhalten dieselben Autorisierungsprüfungen.
Aktualisieren, Zurück‑Navigation und Sitzungsablauf erzeugen verständliche Zustände.
Die Vorschau bleibt bei unterstützten Viewport‑Größen und Zoom‑Stufen nutzbar.
Browser‑Console‑Fehler und fehlgeschlagene Netzwerk‑Anfragen sind im Monitoring sichtbar.
Speicher‑ und Anwendungs‑Logs zeichnen keine Geheimnisse oder vollständigen Dokument‑URLs auf.

Fazit

Die wartungsfreundlichste Doconut‑Einbettung ist die mit einem kleinen, expliziten Vertrag. Lassen Sie Doconut die Dokument‑Anzeige‑Rolle übernehmen, wie in der versionierten Dokumentation beschrieben, während Ihre Anwendung Identität, Autorisierung, Routing, Aufbewahrung, Browser‑Richtlinien und Benutzer‑Feedback besitzt. Wenn Sie bereit sind, die mitgelieferten Beispiele lokal zu prüfen, nutzen Sie die offiziellen Doconut-Download‑Ressourcen statt Quellcode aus einem unverwandten Artikel.