Der offizielle Doconut Funktionskatalog listet Browserdruck und PDF-Export als Viewer‑Funktionen auf. Der Zugriff darauf zu steuern erfordert weiterhin zwei getrennte Entscheidungen: ob Doconut die relevante Aktion anzeigt und ob die Host‑Anwendung diesen Vorgang für den aktuellen Benutzer und das Dokument autorisiert.

Ein Dokumentdruckpfad, der an einem kontrollierten Autorisierungstor endet

Für die genauen von Ihrer installierten Version unterstützten Steuerungen beginnen Sie mit der Doconut Dokumentation und den mitgelieferten Beispielen, die auf der offiziellen Doconut Download‑Seite verfügbar sind. Kopieren Sie keine Konfigurationsschlüssel oder Quellcode aus einer nicht zugehörigen Version oder einem nicht verifizierten Artikel.

1. Definieren Sie zuerst die Druckrichtlinie

Notieren Sie, wer drucken darf und unter welchen Bedingungen, bevor Sie die Symbolleiste ändern. Eine sinnvolle Richtlinie beantwortet Fragen wie:

Ist das Drucken für jeden Betrachter, nur bestimmte Rollen oder bestimmte Dokumente erlaubt?
Hängt die Entscheidung vom Mandanten, dem Fallstatus, der Dokumentklassifizierung oder dem Ablaufdatum ab?
Ist ein Wasserzeichen für die druckbare Ausgabe erforderlich?
Sollten Druckereignisse protokolliert werden?
Kann ein Benutzer eine ältere Dokumentrevision drucken?
Was soll geschehen, wenn sich die Berechtigung ändert, während die Vorschau geöffnet ist?

Vermeiden Sie ein einzelnes globales Boolean, wenn die tatsächliche Regel kontextabhängig ist. Modellieren Sie das Drucken als eigenständigen Vorgang, sodass er unabhängig vom Ansehen und Herunterladen autorisiert werden kann.

2. Trennen Sie UI‑Zustand von der Autorisierung

Die Host‑Seite kann entscheiden, ob sie eine Drucksteuerung anzeigt, nachdem sie ein anwendungs‑eigenes Berechtigungsergebnis erhalten hat. Das verbessert die Klarheit für Benutzer, die nicht drucken können.

Allerdings ist das Verbergen einer Steuerung keine Autorisierungsgrenze. Ein Benutzer kann weiterhin einen bekannten Endpunkt direkt aufrufen, eine frühere Anfrage wiederholen oder den Browserdruck für sichtbare Inhalte auslösen. Jede Server‑Route, die druckbare Ausgaben erzeugt, muss dieselbe Richtlinie durchsetzen.

Verwenden Sie unterschiedliche Zustände in der UI:

Zustand	Verhalten des Viewers	Verhalten des Servers
Drucken erlaubt	Zeige die unterstützte Druckaktion	Autorisiere und erstelle die angeforderte Ausgabe
Drucken verweigert	Verstecke oder deaktiviere die Aktion mit einer klaren Erklärung	Gib eine Fehlermeldung „Verboten“ zurück
Richtlinie unbekannt	Halte die Aktion unverfügbar, während die Berechtigung geladen wird	Erstelle keine Ausgabe
Sitzung abgelaufen	Bitte den Benutzer, sich erneut zu authentifizieren	Verwerfe die veraltete Anfrage

3. Schützen Sie den Druck-Endpunkt

Schützen Sie den Anwendungs‑Vorgang, der das Drucken auslöst oder druckbare Ausgaben zurückgibt. Die Autorisierungsentscheidung sollte die Mandantenmitgliedschaft, Eigentümerschaft, Klassifizierung, den Workflow‑Status und die Dokumentrevision berücksichtigen. Lösen Sie das Dokument auf dem Server auf, anstatt einen vom Client bereitgestellten Pfad oder Speicher‑URL zu akzeptieren.

Wenn Ihre Anwendung über eine viewer‑spezifische Route druckt, anstatt ein PDF zu erstellen, wenden Sie dieselbe Autorisierung an, bevor Sie diese Route aufrufen.

4. Konfigurieren Sie die installierte Viewer‑Version

Sobald die Server‑Regel existiert, konfigurieren Sie die Doconut‑UI mit der exakt dokumentierten Option für das Paket und die Beispiel‑Dateien, die mit Ihrer Version ausgeliefert werden. Die Doconut Live‑Demos ermöglichen es Ihnen, das unterstützte Viewer‑Verhalten zu beobachten, bevor Sie sich auf eine bestimmte Integration festlegen. Überprüfen Sie:

Wo die Option gesetzt wird: Server‑Konfiguration, View‑Model oder Client‑Initialisierung.
Ob sie ein Symbolleisten‑Element ausblendet, eine Aktion deaktiviert oder die erzeugte Ausgabe beeinflusst.
Ob der Wert pro Viewer‑Instanz oder global gilt.
Ob Drucken und Export separate Vorgänge sind.
Ob ein Update den Optionsnamen oder den Standardwert geändert hat.

Betrachten Sie das offizielle Beispiel als die maßgebliche Quelle. Ein plausibel aussehender Property‑Name ist kein ausreichender Beweis dafür, dass der installierte Viewer ihn erkennt.

5. Browser-Druck ehrlich handhaben

Eine Viewer-Einstellung kann nicht garantieren, dass sichtbare Informationen niemals gedruckt oder erfasst werden. Der Browser kann die Host-Seite drucken, und Benutzer können Screenshots oder Fotos machen. Die Abfangung von Tastatureingaben und druckspezifisches CSS können das erwartete Erlebnis verbessern, sind jedoch clientseitige Maßnahmen, die umgangen werden können.

Wenn die Host-Seite keine nützliche Papierkopie erzeugen soll, kann Ihre Anwendung eine eigene druckspezifische Darstellung verwenden, um die Vorschau durch eine erklärende Meldung zu ersetzen. Halten Sie dieses Host-Seiten-Verhalten getrennt von Doconut's dokumentierten Viewer-Steuerungen.

Beschreiben Sie dies nicht als Dokumentenschutz. Verwenden Sie serverseitiges Rendering, Autorisierung, kontrollierte Exporte und sichtbare Wasserzeichen, wenn Ihre Risikobewertung stärkere Abschreckung erfordert.

6. Download, Export und Druck getrennt halten

Benutzer und Entwickler behandeln diese oft als einen einzigen „Read‑Only“-Schalter, aber sie stellen unterschiedliche Datenflüsse dar:

View zeigt gerenderten Inhalt an.
Download liefert die Quelle oder eine andere gespeicherte Datei.
Export erzeugt ein abgeleitetes Format.
Print erzeugt eine druckbare Darstellung oder ruft den Browser‑Druck auf.

Autorisiere jede Operation explizit. Ein Benutzer, der nicht drucken darf, kann dennoch zum Download berechtigt sein, oder umgekehrt. Ihre Symbolleiste sollte die Entscheidungen des Servers widerspiegeln, anstatt sie zu definieren.

7. Nützliche Audit‑Ereignisse hinzufügen

Wenn das Drucken sensibel ist, protokollieren Sie die Entscheidung, ohne das Dokument selbst zu loggen. Ein Ereignis kann den Benutzer, den Mandanten, die Dokumenten‑Kennung, die Revision, das Ergebnis der Richtlinie, den Zeitstempel und die Korrelations‑ID enthalten.

Protokollieren Sie sowohl erfolgreiche als auch verweigerte Versuche. Wenn der Druckservice eine temporäre Datei erstellt, protokollieren Sie auch, ob deren Bereinigung abgeschlossen wurde. Halten Sie Dateipfade, Tokens, Dokumententitel mit personenbezogenen Daten und druckbaren Inhalt aus routinemäßigen Logs heraus.

8. Testen über den fehlenden Button hinaus

Die Symbolleiste ist nur die erste Behauptung. Fügen Sie Tests für den gesamten Vorgang hinzu:

Autorisierter Benutzer

Die beabsichtigte Druckaktion ist sichtbar.
Die Druckanforderung gelingt für ein erlaubtes Dokument.
Die korrekte Revision wird verwendet.
Erforderliche Markierungen erscheinen im erzeugten Output.
Das Audit‑Ereignis protokolliert den Erfolg.

Nicht autorisierter Benutzer

Die Aktion fehlt oder ist deaktiviert.
Eine direkte Anfrage an die Druck‑Route liefert eine verweigerte Antwort.
Das Ändern der Dokument‑ID umgeht die Regel nicht.
Eine aus einer autorisierten Sitzung kopierte URL kann nicht missbräuchlich wiederverwendet werden.
Die Ablehnung gibt nicht preis, ob ein anderer Mandant das Dokument besitzt.

Zustandsänderungen

Während einer Sitzung widerrufene Berechtigung wird bei der nächsten Druckanforderung durchgesetzt.
Eine abgelaufene Sitzung kann nicht drucken.
Ein gelöschtes oder ersetztes Dokument erzeugt einen kontrollierten Fehler.
Temporäre Druckausgaben folgen der konfigurierten Aufbewahrungsregel.

Browser‑Automatisierung kann den sichtbaren Zustand und den Antwortcode überprüfen. Integrationstests sollten die Richtlinienauswertung und die Dokument‑Ebene‑Autorisation unabhängig verifizieren.

Häufige Fragen

Verhindert das Ausblenden des Druck‑Buttons die Druck‑Tastenkombination des Browsers?
Nein. Es entfernt nur eine beabsichtigte Viewer‑Aktion, und das nur, wenn der installierte Viewer dieses Verhalten implementiert. Browser‑Druck und Bildschirmaufnahme erfordern separate Überlegungen und können nicht vollständig durch clientseitigen Code verhindert werden.

Sollte die Druck‑Berechtigung in die Ansicht‑URL aufgenommen werden?
Bevorzugen Sie eine serverseitige Autorisierungsentscheidung, die an den authentifizierten Benutzer, das Dokument und die Operation gebunden ist. Wenn ein temporärer Verweis Berechtigungen trägt, beschränken Sie dessen Geltungsbereich, schützen Sie ihn vor Logs und Referrern und validieren Sie sensible Aktionen erneut.

Reicht das Deaktivieren des Druckens für vertrauliche Dokumente aus?
Nein. Es ist nur eine Usability‑ oder Abschreckungsmaßnahme. Vertrauliche Arbeitsabläufe benötigen zudem Speicherschutz, Objekt‑Ebene‑Autorisation, kontrollierte Exporte, Aufbewahrungsregeln, Monitoring und ein akzeptiertes Restrisiko‑Modell.

Fazit

Eine vertrauenswürdige Doconut‑Druck‑Kontroll‑Implementierung beginnt beim Server und endet in der Benutzeroberfläche. Definieren Sie die Richtlinie, schützen Sie die Operation, konfigurieren Sie nur die dokumentierte Option für Ihren installierten Viewer, erklären Sie das Ergebnis den Benutzern und testen Sie direkte Anfragen sowie die Sichtbarkeit der Symbolleiste. Verwenden Sie die offizielle Feature‑Seite, Dokumentation, Downloads und Demos als Implementierungsquellen, anstatt den Produktcode im Artikel neu zu erstellen.