Das Entfernen einer Download‑Schaltfläche kann einen reinen Anzeigeworkflow unterstützen, verhindert jedoch nicht, dass ein sichtbares Dokument kopiert werden kann. Eine sichere Implementierung erfordert serverseitige Autorisierung, geschützte Speicherung, kurzlebige Sitzungen, sorgfältiges Logging und ein realistisches Verständnis dessen, was UI‑Beschränkungen erreichen können.

Doconut bietet einen eingebetteten .NET‑Dokumentenbetrachter für Business‑Anwendungen. Dieses Tutorial erklärt das zugehörige Sicherheitsdesign, ohne vermutete Konfigurationseigenschaften oder anderen undokumentierten Doconut‑Quellcode zu veröffentlichen.

Verteidigungs‑in‑der‑Tiefe‑Kontrollen, die einen eingebetteten Dokumentenbetrachter schützen und Export‑Aktionen einschränken

1. Definieren, was „Nur-Anzeigen“ bedeutet

Starten Sie mit einer präzisen Richtlinie. Unterschiedliche Teams können „Nur-Anzeigen“ folgendermaßen verstehen:

Stellen Sie die Originaldatei nicht als Download bereit.
Zeigen Sie keine Export‑Aktion an.
Erlauben Sie kein Drucken.
Erlauben Sie das Anzeigen nur während einer autorisierten Sitzung.
Verhindern Sie, dass Benutzer den Speicherort direkt erreichen.
Fügen Sie Audit‑Einträge hinzu, wenn ein Dokument geöffnet wird.

Dies sind separate Kontrollen. Entscheiden Sie, welche erforderlich sind, und prüfen Sie, dass Ihr ausgewähltes Doconut‑Produkt, die Plugins und die Lizenz das gewünschte Viewer‑Verhalten unterstützen.

Versprechen Sie niemals, dass ein sichtbares Dokument nicht erfasst werden kann. Screenshots, Kameras, Barrierefreiheits‑Tools, Browser‑Funktionen und autorisierter Zugriff auf angezeigte Pixel machen eine absolute Verhinderung unrealistisch.

2. Originaldatei schützen

Das Originaldokument sollte in geschütztem serverseitigem Speicher verbleiben.

Verwenden Sie:

Serverseitig generierte Dokumenten‑IDs
Eingeschränkte Speicherberechtigungen
Verschlüsselung im Ruhezustand, wo erforderlich
Eine dokumentierte Aufbewahrungsrichtlinie
Separate Berechtigungen für Hochladen, Anzeigen, Exportieren und Verwaltung

Senden Sie keine Speicheranmeldeinformationen, uneingeschränkten Dateipfade oder permanente öffentliche URLs an den Client.

3. Jede Dokumentanforderung autorisieren

In ASP.NET Core schützen Sie die Viewer‑Route mit den üblichen Authentifizierungs‑ und Autorisierungsmechanismen.

Der Server sollte prüfen:

Der Benutzer ist authentifiziert.
Das Dokument existiert.
Der Benutzer darf dieses spezifische Dokument ansehen.
Die angeforderte Aktion ist für die Rolle des Benutzers und den aktuellen Workflow‑Zustand erlaubt.

Das [Authorize]‑Attribut kann eine Route schützen, während Richtlinien, Claims oder ressourcenbasierte Autorisierung die dokumentenspezifische Entscheidung treffen können.

Die Autorisierung muss auch jedes Endpunkt abdecken, das Dokumentdaten, Seiten, Exporte, Anmerkungen oder Druckausgaben zurückgibt. Nur die Anfangsseite zu sichern lässt alternative Routen offen.

4. Ansicht‑ und Download‑Berechtigungen trennen

Modellieren Sie Berechtigungen explizit, anstatt sie aus einer versteckten Schaltfläche abzuleiten.

Beispiel:

CanViewDocument
CanDownloadOriginal
CanExportDocument
CanPrintDocument
CanManageDocument

Diese Namen beschreiben Anwendungspolicen, nicht Doconut‑APIs. Ihre Autorisierungsschicht sollte sie auf dem Server auswerten, bevor die entsprechende Aktion ausgeführt wird.

Ein Administrator kann die Download‑Berechtigung besitzen, während ein anderer authentifizierter Benutzer nur die Ansicht‑Berechtigung hat. Beide Benutzer können dieselbe Anwendungsseite nutzen, erhalten jedoch unterschiedliche autorisierte Fähigkeiten.

5. Viewer aus offizieller Dokumentation konfigurieren

Verwenden Sie ausschließlich die Konfigurationsnamen und Integrationsschritte, die für die exakt installierte Doconut‑Version in Ihrer Anwendung dokumentiert sind.

Die verifizierte Doconut Viewer‑Seite liefert aktuelle Produktinformationen. Die Doconut Download‑ und Dokumentationsseite stellt Installationsressourcen und versionsspezifische Beispiele bereit.

Falls das installierte Produkt eine unterstützte Einstellung zum Ausblenden oder Deaktivieren einer Download‑Aktion bereitstellt:

Wenden Sie es gemäß der offiziellen Dokumentation an.
Betrachten Sie es als UI‑ und Workflow‑Kontrolle.
Halten Sie den zugehörigen Server‑Endpunkt geschützt.
Testen Sie, dass unautorisierte Benutzer es nicht mit einer direkten Anfrage umgehen können.

Kopieren Sie keine vermuteten Konfigurationseigenschaften aus einem fremden Artikel und gehen Sie nicht davon aus, dass sie unterstützt werden.

6. Viewer‑Integration hinter einem Service halten

Ein dedizierter Anwendungs‑Service kann:

Das autorisierte Dokument ermitteln
Es über eine genehmigte Speicherabstraktion öffnen
Unterstützte Viewer‑Konfiguration anwenden
Streams und temporäre Ressourcen freigeben
Bereinigte Audit‑Ereignisse protokollieren
Sichere Fehlermeldungen an den Controller zurückgeben

Damit bleiben SDK‑spezifische Details aus Autorisierungspolicen und Präsentationscode heraus.

Standard‑.NET‑Typen wie Stream, FileStream, CancellationToken und dependency‑injected Services können die umgebende Anwendungsgrenze bilden. Folgen Sie Doconut’s eigener Dokumentation für Aufrufe in das SDK.

7. Defense-in-Depth anwenden

Ein reiner Anzeigeworkflow kann umfassen:

Authentifizierung und ressourcenbasierte Autorisierung
Netzwerk‑ und Speicherisolation
Kurze Sitzungsdauer
Eingeschränkte Export‑ und Druck‑Routen
Wasserzeichen, wenn unterstützt und angemessen
Audit‑Ereignisse für Dokumentzugriff
Ratenbegrenzungen und Nebenläufigkeits‑Kontrollen
Klare Aufbewahrungs‑ und Bereinigungsregeln
Sicherheitsüberwachung bei ungewöhnlichen Zugriffsmustern

Keine einzelne Kontrolle ist ausreichend. Eine versteckte Schaltfläche ohne Server‑Schutz ist besonders leicht zu umgehen.

8. Zugriff protokollieren, ohne Daten zu leaken

Nützliche Audit‑Felder umfassen:

Anwendungs‑Dokumenten‑ID
Autorisierten Benutzer‑ID
Zeitstempel
Angeforderte Aktion
Ergebnis
Korrelations‑ID
Bereinigter Grund für Ablehnung oder Fehler

Vermeiden Sie das Protokollieren von:

Dokumentinhalten
Speicheranmeldeinformationen
Zugriffstoken
Sensiblen URLs
Vollen Serverpfaden
Unnötigen persönlichen Informationen

Schützen Sie Audit‑Logs gemäß ihrer Sensitivität und Aufbewahrungsanforderungen.

9. Versuche testen, die UI zu umgehen

Stoppen Sie nicht, nachdem Sie bestätigt haben, dass eine Symbolleisten‑Schaltfläche fehlt.

Testen Sie, ob ein Nur‑Anzeige‑Benutzer kann:

Die Originaldatei‑Route direkt anfordern
Eine Export‑ oder Druck‑Route aufrufen
Einen Dokumenten‑Identifier ändern
Eine abgelaufene Sitzung wiederverwenden
Auf das Dokument eines anderen Benutzers zugreifen
Speicher‑URLs im Markup oder Netzwerk‑Antworten entdecken
Ausführliche Fehlermeldungen auslösen, die interne Pfade offenbaren
Zugriff behalten, nachdem ihre Berechtigung widerrufen wurde

Beziehen Sie sowohl automatisierte Autorisierungstests als auch manuelle Browser‑Tests ein.

10. Realistische Benutzererwartungen setzen

Erklären Sie, was die Richtlinie bewirkt:

Sie begrenzt von der Anwendung bereitgestellte Download‑ oder Export‑Workflows.
Sie beschränkt den Zugriff auf autorisierte Benutzer.
Sie kann Anzeigeveranstaltungen protokollieren.
Sie hält die Originaldatei hinter Server‑Kontrollen.

Erklären Sie außerdem, was sie nicht garantieren kann:

Sie kann Fotografie oder Screenshots in jeder Umgebung nicht verhindern.
Sie kann bereits gesehene und erinnerte Informationen nicht zurückziehen.
Sie ersetzt keine vertraglichen, organisatorischen oder Endgerätesicherheits‑Kontrollen.

Diese Unterscheidung macht das Produkt vertrauenswürdiger und hilft Stakeholdern, geeignete Kontrollen für hochsensible Materialien auszuwählen.

Prüfliste

Anzeigen und Herunterladen verwenden separate Server‑Berechtigungen.
Jede Dokumentanforderung führt ressourcenbasierte Autorisierung durch.
Die Originaldatei hat keine permanente öffentliche URL.
Viewer‑Einstellungen stammen aus der Dokumentation für die installierte Doconut‑Version.
Versteckte Aktionen haben geschützte Server‑Endpunkte.
Temporäre Daten haben einen definierten Bereinigungsprozess.
Audit‑Logs vermeiden Dokumentinhalte und Geheimnisse.
Unautorisierte direkte Anfragen werden durch Tests abgedeckt.
Fehlerantworten geben keine internen Speicherdetails preis.
Produkttexte behaupten nicht, dass Kopierschutz absolut ist.

Wo Doconut passt

Doconut stellt die eingebettete Ansichtsschicht innerhalb der .NET‑Anwendung bereit. Ihre Anwendung bleibt verantwortlich für Identität, Autorisierung, Berechtigungen, Speicherung, Aufbewahrung, Auditing und die Wahrhaftigkeit des „Nur‑Anzeige“‑Versprechens.

Bewerten Sie das Doconut .NET Dokumentenbetrachter SDK anhand Ihrer Sicherheitsanforderungen und repräsentativen Dokumente. Nutzen Sie die offiziellen Ressourcen für unterstützte Konfigurationen, anstatt sich auf vermuteten Quellcode zu verlassen.

Fazit

Ein reiner Anzeigedokument‑Workflow ist ein Defense‑in‑Depth‑Design, kein boolesches Flag. Schützen Sie die Originaldatei, autorisieren Sie jede Anfrage, trennen Sie Ansicht‑ und Download‑Berechtigungen, validieren Sie unterstützte Viewer‑Einstellungen, auditieren Sie den Zugriff und testen Sie direkte Versuche, die Schnittstelle zu umgehen.

Mit diesen Kontrollen kann Doconut das eingebettete Dokumentenerlebnis bereitstellen, während Ihre ASP.NET‑Anwendung die Sicherheitsrichtlinie darum herum durchsetzt.