Viele Entwickler beginnen damit, nach UI‑Komponentenbibliotheken zu suchen, wenn sie Dokumente in einer Webanwendung anzeigen müssen. Doconut Viewer ist ein .NET‑SDK, das plugin‑freies Browsen in ASP.NET Core, MVC oder klassischen WebForms‑Projekten ermöglicht. Sicherheit hängt weiterhin von der gesamten Anwendungsarchitektur ab: Authentifizierung, Autorisierung, Transport, Speicherung, Validierung, Bereinigung, Patchen und Überwachung.
1. Installieren Sie das Doconut App SDK und bereiten Sie Ihr .NET‑Projekt für mehrere Dateiformate vor
1.1 Unterstütztes Paket hinzufügen
Verwenden Sie das aktuelle Paket und die Installationsanweisungen von der offiziellen Doconut-Downloadseite. Notieren Sie die gewählte Version und prüfen Sie, dass sie die Ziel‑.NET‑Runtime unterstützt.
1.2 Paketreferenz überprüfen
Nach der Installation bestätigen Sie die Paketreferenz und die aufgelöste Version in der Projektdatei. Explizite Versionsangaben helfen, Builds und Deployments reproduzierbar zu machen.
1.3 HTTPS aktivieren
Stellen Sie die Anwendung über HTTPS bereit, damit hochgeladene Dokumente nicht im Klartext über Ihr Netzwerk übertragen werden. Für eine Kestrel‑gehostete App fügen Sie eine Endpunktkonfiguration in appsettings.json hinzu:
{
"Kestrel": {
"Endpoints": {
"Https": {
"Url": "
}
}
}
}
Wenn Sie auf IIS hosten, binden Sie ein HTTPS‑Zertifikat an die Site. Mit aktiviertem HTTPS wird die Datei über einen sicheren Kanal zu Ihrem eigenen Server übertragen, wo das SDK sie rendert.
Woher die Sicherheit kommt.
Das SDK läuft innerhalb Ihrer Anwendung, auf Ihrer Infrastruktur: Es stellt keine Aufrufe zu Doconut‑Servern her, sodass Dokumente Ihr Netzwerk nie verlassen. Das ist die Eigenschaft, um die herum man designen sollte. Es ist kein Compliance‑Zertifikat – das SDK liefert keine eigene ISO‑27001-, SOC‑2- oder HIPAA‑Bestätigung und kann Ihrer Anwendung keine verleihen. Was es tut, ist die Datei innerhalb einer Grenze zu halten, die Sie bereits kontrollieren und auditieren.
2. Sichere Dateiuploads und Speicherung für das Dokumentenmanagement konfigurieren
Dies ist der Teil, der Ihnen und nicht dem SDK gehört, und es ist wichtig, das klar zu sagen: Transport‑Sicherheit, Verschlüsselung im Ruhezustand, Aufbewahrung und Bereinigung sind Entscheidungen, die Ihre Anwendung trifft. Das SDK rendert Dokumente; es ist keine Speicherschicht und verschlüsselt Ihre Festplatte nicht für Sie.
2.1 Dienste registrieren
In Startup.cs (oder Program.cs bei modernem .NET) registrieren Sie die Doconut‑Dienste im Dependency‑Injection‑Container gemäß der Dokumentation für die von Ihnen installierte Version. Wenn das SDK einen Arbeitsordner für temporäre Renderausgaben benötigt, verweisen Sie ihn auf einen Ort, den Sie kontrollieren, und übernehmen Sie die Bereinigung dieses Ordners – z. B. durch einen geplanten Job oder eine anwendungsverwaltete Lebensdauer, nicht durch Annahmen.
2.2 Upload‑Endpunkt erstellen
Implementieren Sie eine Controller‑Aktion, die eine hochgeladene Datei empfängt, sie in den von Ihrer Anwendung bereits genutzten Speicher schreibt und ein kurzes Einmal‑Token zurückgibt. Das Token wird vom clientseitigen Viewer verwendet, um das Dokument abzurufen und zu rendern. Beachten Sie, dass die Speicherung Ihre Aufgabe ist: Sie übergeben dem SDK die Bytes oder den Pfad, wenn es Zeit zum Rendern ist, und es gibt Ihnen die Seiten zurück.
2.3 Endpunkt schützen
Da der Upload‑Endpunkt mit sensiblen Daten arbeitet, schützen Sie ihn mit Authentifizierung und rollenbasierter Autorisierung (z. B. dürfen nur Benutzer mit der Rolle DocumentViewer hochladen). Validieren Sie die Dateierweiterung und die Größe sowohl serverseitig als auch im Browser und behandeln Sie die hochgeladenen Bytes als nicht vertrauenswürdige Eingabe.
Überspringen Sie dies nicht in der Annahme, dass das SDK es abdeckt. Verschlüsselung im Ruhezustand, Schlüsselverwaltung und Bereinigung verwaister Dateien sind Aufgaben Ihrer Anwendung. Wenn Sie Dokumente auf der Festplatte verschlüsseln müssen, nutzen Sie die Plattform‑Funktionen, denen Sie bereits vertrauen – der Viewer ist nicht der richtige Ort dafür.
3. Einbetten der Viewer‑Komponente in ASP.NET Core, MVC oder WebForms
Nachdem das Backend bereit ist, initialisieren Sie den Viewer mit den Assets und der API, die für die installierte Doconut-Version dokumentiert sind.
3.1 JavaScript‑Bundle hinzufügen
Fügen Sie in Ihrem gemeinsamen Layout nur die Viewer‑Ressourcen ein, die in der Dokumentation für das installierte SDK beschrieben werden. Gehen Sie nicht davon aus, dass Bundle‑Namen oder -Standorte versionsübergreifend fest sind.
3.2 Razor‑View für Core/MVC erstellen
Fügen Sie eine View hinzu (z. B. Views/Document/View.cshtml), die ein Dateieingabefeld, ein Container‑Element für den Viewer und ein kleines Skript enthält, das die ausgewählte Datei hochlädt, das sichere Token empfängt und das Doconut Viewer‑Widget initialisiert.
Das Skript sollte:
- Die ausgewählte Datei aus dem
<input type="file">‑Element erfassen. - Die Datei an den Upload‑Endpunkt mit
fetchoderXMLHttpRequestsenden. - Wenn die autorisierte Antwort eintrifft, den Viewer mit der unterstützten API für die installierte Version initialisieren.
3.3 Äquivalent für WebForms
Platzieren Sie auf einer WebForms‑Seite (z. B. DocumentViewer.aspx) ein asp:FileUpload‑Steuerelement, einen Button zum Auslösen des Uploads und ein <div>, das den Viewer hosten wird. Im Code‑Behind rufen Sie den Doconut‑Dienst auf, um die hochgeladene Datei zu speichern, das Token zu erhalten und ein Start‑Skript zu registrieren, das eine JavaScript‑Funktion (initViewer(token)) aufruft, um die Viewer‑Instanz zu erstellen.
Der Grund, dies so zu machen: ein Rendering‑Pfad, der drei .NET‑UI‑Modelle bedient, ohne dass auf dem Endbenutzer‑Computer etwas installiert sein muss.
4. Viewer für Dokumentenmanagement anpassen
Der Viewer wird innerhalb eines Containers auf Ihrer eigenen Seite gerendert, sodass die umgebende Anwendung bereits Ihnen gehört. Darüber hinaus übernehmen Sie die Optionsnamen und Standardwerte aus der Dokumentation für die installierte Version und nicht aus einem Tutorial, dieses eingeschlossen – die Konfigurationsoberfläche ändert sich zwischen den Releases und ein fest codierter Optionsname ist am ehesten von einem Upgrade betroffen.
Die Punkte, die im Vorfeld entschieden werden sollten:
4.1 Welche Steuerelemente der Benutzer erhält
Entscheiden Sie, ob Ihre Benutzer die Originaldatei herunterladen können sollen oder nur die gerenderten Seiten lesen dürfen. Kontrolliertes Drucken ist Teil des Viewers und nicht ein separater Kauf, sodass Druckregeln eine Konfigurationsfrage und keine Lizenzfrage sind.
4.2 Welche Plugins Sie tatsächlich benötigen
Vier werden separat lizenziert, und die Liste ist kurz genug, um sie sich zu merken: Annotation, Converter, DICOM und Search. Konvertierung – DOC zu PDF und das übrige – ist das Converter‑Plugin. Textsuche ist das Search‑Plugin. Wenn Sie keines benötigen, kaufen Sie keines.
4.3 Lokalisierung
Wenn Ihre Anwendung mehrsprachig ist, prüfen Sie, welche UI‑Zeichenketten der Viewer in der installierten Version bietet, bevor Sie das Design darauf abstimmen.
Warum das wichtig ist: Der Viewer sollte wie ein Teil Ihres Produkts aussehen. Er sollte nicht stillschweigend Ihren Benutzern Fähigkeiten versprechen, die in der von Ihnen erworbenen Lizenz nicht enthalten sind.
5. Integration über alle unterstützten Formate testen
Bevor Sie live gehen, führen Sie einen schnellen Plausibilitätstest für jeden Dateityp durch, den Ihre Benutzer voraussichtlich ansehen werden. Öffnen Sie mit dem Viewer der Doconut‑App eine Beispieldatei jedes Formats und prüfen Sie, ob Rendering, Navigation und alle speziellen Werkzeuge wie beschrieben funktionieren.
| Format | Testscenario | Erwartetes Ergebnis |
|---|---|---|
| Großer, mehrseitiger Bericht mit eingebetteten Bildern | Flüssiges Scrollen, Zoomen und genaue Farbdarstellung | |
| DOCX | Word‑Dokument mit Tabellen und Fußnoten | Alle Texte, Tabellen und Fußnoten sichtbar; keine Layoutverschiebung |
| XLSX | Tabellenkalkulation mit Diagrammen | Diagramme werden als Vektorgrafiken gerendert; beim Zoomen bleibt die Klarheit erhalten |
| PPTX | Präsentation mit animierten Aufbauten | Jeder Aufbau auf einer Folie wird gestapelt in einem Frame gerendert – das ist beabsichtigt, kein Fehler |
| DWG | Technische Zeichnung mit Ebenen und externen Referenzen | Ebenen lassen sich ein‑ und ausblenden, Abstand‑ und Flächenmessungen funktionieren; XRefs und SHX‑Schriften fehlen, weil sie nie in der Datei waren |
| PSD | Ebenen‑Photoshop‑Datei | Die gespeicherte Komposition wird gerendert, versteckte Ebenen bleiben verborgen; Farben bleiben beim Zoomen erhalten |
| SVG | Vektorgrafik mit Farbverläufen | Farbverläufe werden flüssig gerendert; das Zoomen bleibt scharf |
| TIFF | Hochauflösender Scan | Bild lädt schnell; beim Zoomen werden Details sichtbar |
Testen Sie mit den echten Dateien Ihrer Benutzer, nicht mit sauberen Beispielen. Die Formate, die Menschen überraschen, sind diejenigen, deren Eigenheiten im Format selbst liegen – ein DWG, das vier weitere Zeichnungen referenziert, eine Tabellenkalkulation, deren gespeicherte Werte nie neu berechnet wurden, oder eine Präsentation, deren Schriftarten nicht eingebettet waren. Der kostenlose Viewer unter Doconut.app verwendet dieselbe Engine, sodass er eine schnelle Möglichkeit bietet, zu sehen, wie eine bestimmte schwierige Datei aussieht, bevor Sie Code schreiben.
Fazit
Die Einbettung eines plug‑in‑freien Dokumentenbetrachters lässt sich auf vier Dinge reduzieren: das SDK installieren, Ihren eigenen Upload‑Pfad sichern, in einen Container auf Ihrer Seite rendern und nur das konfigurieren, was die installierte Version dokumentiert. Der Beitrag des Betrachters zur Sicherheit ist eng und real — er läuft auf Ihren Servern und sendet nichts nach außen. Alles andere auf dieser Liste gehört zu Ihrer Anwendung, und kein SDK kann das für Sie übernehmen.
Bereit, es zu evaluieren? Beginnen Sie mit der offiziellen Doconut‑Download‑ und Dokumentationsseite und testen Sie das SDK im Rahmen derselben Sicherheitsüberprüfung, die auch für den Rest Ihrer Windows‑basierten ASP.NET‑Anwendung gilt.