Das Hinzufügen einer Dokumentenanzeige zu einer Business‑Anwendung erfordert mehr als das Einbetten einer PDF in ein iframe. Office‑Dateien, CAD‑Zeichnungen, E‑Mail‑Dateien und Bilder benötigen unterschiedliche Rendering‑Fähigkeiten, während die Anwendung weiterhin Authentifizierung, Speicherung, Autorisierung und Aufbewahrung steuern muss.
Doconut ist ein .NET‑Dokumenten‑Viewer‑SDK, das das Einbetten von Dokumenten‑Rendering und Interaktion in Web‑Anwendungen ermöglicht. Anstatt ein nicht verifiziertes Quellcode‑Rezept zu präsentieren, erklärt dieser Leitfaden die Integrationsentscheidungen, die Ihr Team treffen sollte, und identifiziert die standardmäßigen .NET‑Komponenten, die das SDK typischerweise umgeben.
Warum ein eingebetteter Viewer sich vom Herunterladen einer Datei unterscheidet
Ein Download‑Endpunkt überträgt die Originaldatei und überlässt das Anzeigeerlebnis einer Software außerhalb Ihrer Anwendung. Ein eingebetteter Viewer hält den Benutzer innerhalb Ihres Produkts und kann einen konsistenten Ort für Navigation, Suche, Überprüfung und andere aktivierte Funktionen bieten.
Das eigene Rendering‑Layer zu bauen ist schwierig, weil jedes Format seine eigenen Regeln hat:
- PDF‑Dateien können eingebettete Schriften, Anmerkungen, Formulare und sehr große Seitensätze enthalten.
- Word‑, Excel‑ und PowerPoint‑Dateien erfordern sorgfältige Layout‑ und Schriftverwaltung.
- CAD‑Zeichnungen benötigen genaue Skalierung, Ebenen und detaillierten Zoom.
- E‑Mail‑ und Bildformate bringen Anhänge, Metadaten, Farb‑ und Auflösungsaspekte mit.
Ein dediziertes SDK ermöglicht es dem Anwendungsteam, sich auf Zugriffskontrolle, Workflows und Benutzererlebnis zu konzentrieren, anstatt einen separaten Renderer für jedes unterstützte Format zu warten.
Schritt 1: Bestätigen Sie die erforderlichen Formate und Funktionen
Beginnen Sie mit einer realen Inventur der Dateien, die Ihre Benutzer öffnen. Trennen Sie wesentliche Formate von gelegentlichen und erfassen Sie repräsentative Beispiele zum Testen.
Ihre Checkliste könnte Folgendes enthalten:
- PDF‑ und XPS‑Dokumente
- Textverarbeitungs‑Dokumente
- Tabellenkalkulationen
- Präsentationen
- CAD‑Zeichnungen
- E‑Mail‑Dateien
- Gängige Bildformate
Identifizieren Sie dann die Funktionen, die für jeden Workflow wichtig sind. Anzeige, Textsuche, Anmerkungen, Drucken und Konvertierung sind unterschiedliche Fähigkeiten und können verschiedene Doconut‑Komponenten oder Lizenzen erfordern.
Überprüfen Sie den aktuellen Produktumfang auf der verifizierten Doconut Viewer‑Seite, bevor Sie sich für ein Format oder eine Funktion festlegen. Produktfähigkeiten können sich ändern, daher sollten Ihre Akzeptanztests die endgültige Autorität für die Dokumente sein, die Ihre Kunden tatsächlich verwenden.
Schritt 2: Entscheiden Sie, wo Dokumente in die Anwendung gelangen
Eine ASP.NET‑Anwendung kann Dokumente aus mehreren kontrollierten Quellen erhalten:
- Ein Upload, verarbeitet als ASP.NET Core
IFormFile - Ein geschützter Dateistandort
- Eine Datenbank oder ein Dokument‑Management‑Repository
- Objektspeicher, auf den der Server zugreift
- Ein interner Service, der einen
Streamzurückgibt
Der Anzeige‑Workflow sollte eine server‑autorisiert Referenz auf das Dokument verwenden. Legen Sie keine Speicher‑Anmeldeinformationen, uneingeschränkten Dateipfade oder permanente öffentliche URLs im clientseitigen Markup ab.
Wenn Benutzer Dateien hochladen, validieren Sie diese vor dem Rendering. Prüfen Sie Dateigröße, Erweiterung, Dateisignatur und etwaige geschäftsspezifische Einschränkungen. Speichern Sie die vom Server erzeugte Kennung, anstatt dem ursprünglichen Dateinamen als Pfad zu vertrauen.
Schritt 3: Definieren Sie Authentifizierung und Autorisierung
Die Anwendung – nicht die Viewer‑UI – sollte entscheiden, wer ein Dokument öffnen darf.
In ASP.NET Core können Standardmechanismen wie Authentifizierungs‑Middleware, das [Authorize]‑Attribut, Richtlinien, Claims und ressourcenbasierte Autorisierung den Endpunkt schützen, der eine Ansichtssitzung startet. Die Autorisierungsentscheidung sollte sowohl den aktuellen Benutzer als auch das angeforderte Dokument berücksichtigen.
Ein sicherer Anforderungsablauf sieht folgendermaßen aus:
- Der Benutzer fordert ein Dokument mittels einer anwendungsspezifischen Kennung an.
- Der Server authentifiziert den Benutzer.
- Der Server prüft, ob der Benutzer auf dieses spezielle Dokument zugreifen darf.
- Der Server ermittelt den geschützten Speicherort.
- Der Viewer erhält nur die Informationen, die für diese autorisierte Sitzung nötig sind.
Gehen Sie niemals davon aus, dass das Verstecken eines Toolbar‑Buttons eine Autorisierungskontrolle darstellt. Serverseitige Zugriffsprüfungen bleiben notwendig, selbst wenn Download‑ oder Druck‑Steuerelemente nicht angezeigt werden.
Schritt 4: Fügen Sie Doconut über die offiziellen Integrationsressourcen hinzu
Verwenden Sie das aktuelle Paket und die Installationsanweisungen, die von Doconut bereitgestellt werden. Die verifizierte Doconut‑Download‑Seite bietet Zugriff auf NuGet‑Integrationsressourcen, Dokumentation, Beispiele und Demos.
Die genaue Einrichtung kann abhängen von:
- Ihrem ASP.NET‑ oder .NET‑Anwendungstyp
- Dem ausgewählten Doconut‑Produkt und den Plugins
- Der Doconut‑Version
- Ihrer Lizenz
- Den Dokumenten‑Formaten und Funktionen, die Sie aktivieren
- Ihrer Windows‑Server‑Konfiguration
Befolgen Sie die Dokumentation, die zur installierten Version passt. Vermeiden Sie das Kopieren von Initialisierungsschnipseln aus unverwandten Blog‑Posts, da Namespaces, Konfiguration, Asset‑Pfade und APIs zwischen Versionen variieren können.
Schritt 5: Erstellen Sie eine dedizierte Viewing‑Grenze
Halten Sie die Dokumentenanzeige hinter einem kleinen Anwendungs‑Service, anstatt SDK‑Funktionalität über Controller und UI‑Komponenten zu verstreuen.
Dieser Service kann verantwortlich sein für:
- Auflösen einer autorisierten Dokumenten‑Kennung
- Öffnen des Dokuments als kontrollierten
Stream, wenn nötig - Bereitstellung der erforderlichen Anzeige‑Konfiguration
- Freigabe von Datei‑ und Stream‑Ressourcen
- Übersetzung technischer Fehler in sichere Anwendungs‑Fehlermeldungen
- Aufzeichnung betrieblicher Metriken, ohne Dokumenteninhalte zu protokollieren
Diese Grenze erleichtert Upgrades und reduziert das Risiko, Speicher‑Details an die Präsentationsschicht zu leaken. Sie gibt Tests zudem einen klaren Ort, um eine sichere Implementierung zu substituieren.
Schritt 6: Gestalten Sie die Viewer‑Seite
Der Viewer sollte genug Platz bieten, um nützlich zu sein. Eine schmale Karte, umgeben von unrelated controls, erschwert die Inspektion großer Tabellenkalkulationen und CAD‑Zeichnungen.
Planen Sie die Seite um:
- Eine stabile Viewer‑Höhe
- Klare Lade‑, Leere‑ und Fehlermeldungs‑Zustände
- Einen prägnanten Dokumententitel
- Tastatur‑zugängliche umgebende Steuerelemente
- Ein Layout, das wichtige Viewer‑Steuerungen nicht verbirgt
- Einen eindeutigen Weg, zum übergeordneten Workflow zurückzukehren
Testen Sie mit langen Dateinamen, großen Seitenzahlen, breiten Tabellen, detaillierten Zeichnungen und Dokumenten, die nicht rendern. Der Fehlermeldungs‑Zustand sollte keine Server‑Pfade, Ausnahme‑Traces oder Speicher‑URLs preisgeben.
Schritt 7: Verwalten Sie Dateien und temporäre Daten
Definieren Sie vor dem Rollout eine Aufbewahrungsrichtlinie. Betrachten Sie die Originaldatei, temporäre Renderdaten, Caches, Exporte, Anmerkungen und Protokolle separat.
Nützliche Schutzmaßnahmen umfassen:
- Ein dediziertes temporäres Verzeichnis mit eingeschränkten Berechtigungen
- Eindeutige, vom Server generierte Namen
- Aufräumen nach abgeschlossenen und fehlgeschlagenen Sitzungen
- Einen geplanten Prozess für verlassene temporäre Dateien
- Speicher‑Quoten und Monitoring
- Verschlüsselung im Ruhezustand, wo Ihre Sicherheits‑Richtlinie dies verlangt
Machen Sie das Aufräumen beobachtbar. Wenn das Löschen stillschweigend fehlschlägt, können temporäre Dateien ansammeln und sowohl betriebliche als auch sicherheitsrelevante Probleme verursachen.
Schritt 8: Konfigurieren Sie Produktions‑Sicherheitsmaßnahmen
Dokumenten‑Rendering kann CPU, Arbeitsspeicher und temporären Festplattenspeicher beanspruchen. Schützen Sie die Anwendung mit expliziten Limits:
- Maximale Upload‑Größe
- Maximale gleichzeitige Rendering‑Jobs
- Anfragen‑ und Verarbeitungs‑Timeouts
- Warteschlangen‑Limits, wenn Rendering asynchron erfolgt
- Temporäre Speicher‑Quoten
- Gesundheits‑Checks und strukturierte Fehler‑Überwachung
Bei großen oder unvorhersehbaren Workloads isolieren Sie das Rendering von latenz‑sensitiven Anwendungs‑Prozessen. Messen Sie mit kundenähnlichen Dokumenten statt nur mit kleinen Testdateien.
Schritt 9: Testen Sie den kompletten Workflow
Ein erfolgreicher Integrationstest sollte mehr abdecken als „die erste Seite erschien“.
Testen Sie:
- Jedes erforderliche Dateiformat
- Kleine, große, mehrseitige und beschädigte Dateien
- Dokumente mit ungewöhnlichen Schriften
- Passwortgeschützte Dateien, wenn Ihr Workflow diese unterstützt
- Autorisierte und nicht autorisierte Benutzer
- Gleichzeitige Ansichtssitzungen
- Anwendungs‑Neustarts und unterbrochene Anfragen
- Aufräumen nach Erfolg und Misserfolg
- Viewer‑Funktionen, die in Ihrer ausgewählten Produktkonfiguration enthalten sind
Pflegen Sie eine versionierte Sammlung bereinigter Testdokumente. Führen Sie sie erneut aus, wenn Sie Doconut, .NET, Windows Server, Speicher‑Infrastruktur oder verwandte Abhängigkeiten aktualisieren.
Sicherheits‑Checkliste
Vor der Veröffentlichung prüfen Sie, dass:
- Jede Ansicht‑Anfrage dort authentifiziert wird, wo es nötig ist.
- Die Autorisierung für das spezifische Dokument geprüft wird.
- Benutzereingaben nicht zu einem uneingeschränkten Server‑Dateipfad werden können.
- Speicher‑Anmeldeinformationen niemals den Client erreichen.
- Upload‑Limits und Validierung aktiviert sind.
- Temporäre Dateien eingeschränkten Zugriff haben und eine getestete Aufräum‑Richtlinie besitzen.
- Protokolle keine Dokumenteninhalte, Geheimnisse oder sensible URLs enthalten.
- Fehlermeldungen, die dem Benutzer gezeigt werden, gesäubert sind.
Viewer‑Steuerungen können Ihren Geschäfts‑Workflow unterstützen, verhindern jedoch nicht jede Form der Erfassung, sobald Informationen einem autorisierten Benutzer sichtbar sind. Nutzen Sie sie zusammen mit Zugriffskontrollen und einer geeigneten Informations‑Schutz‑Richtlinie.
Wo Doconut hineinpasst
Doconut liefert die Dokumenten‑Anzeige‑Funktionalität innerhalb der .NET‑Anwendung, während Ihre Anwendung für Identität, Autorisierung, Dateispeicherung, Aufbewahrung, Auditing und den umgebenden Workflow verantwortlich bleibt.
Diese Aufgabenteilung bietet .NET‑Teams einen praktischen Weg, Geschäftsdokumente zu unterstützen, ohne mehrere Rendering‑Engines von Grund auf zu bauen. Gleichzeitig bleiben produktspezifische Integrationsdetails an die offizielle Dokumentation der eingesetzten Version gebunden.
Entdecken Sie das Doconut .NET Dokumenten‑Viewer‑SDK und nutzen Sie anschließend die offiziellen Download‑ und Dokumentations‑Ressourcen, um es mit Ihren eigenen Dokumenten zu evaluieren.
Fazit
Ein zuverlässiger eingebetteter Dokumenten‑Viewer beginnt mit klaren Format‑Anforderungen und einem sicheren serverseitigen Dokumenten‑Flow. Validieren Sie Eingaben, autorisieren Sie jede Dokumenten‑Anfrage, isolieren Sie den SDK‑Zugriff hinter einem Anwendungs‑Service, planen Sie das Aufräumen temporärer Dateien und testen Sie mit realistischen Dateien.
Mit diesen Grundlagen kann Doconut die Anzeige‑Schicht für Ihre Windows‑basierte .NET‑Web‑Anwendung bereitstellen, während Ihr Team die Kontrolle über die Anwendungs‑Architektur und den Dokumenten‑Lebenszyklus behält.