Der offizielle Doconut Funktionskatalog listet Browser‑Druck und PDF‑Export als Viewer‑Funktionen auf. Der Zugriff darauf zu steuern erfordert weiterhin zwei getrennte Entscheidungen: ob Doconut die relevante Aktion anbietet und ob die Host‑Anwendung diese Operation für den aktuellen Benutzer und das Dokument autorisiert.

Ein Dokument‑Druckpfad, der an einem kontrollierten Autorisierungstor endet

Für die genauen Steuerungen, die Ihre installierte Version unterstützt, 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 Viewer, nur bestimmte Rollen oder bestimmte Dokumente erlaubt?
Hängt die Entscheidung vom Mandanten, Fallstatus, Dokumentklassifizierung oder Ablaufdatum ab?
Ist ein Wasserzeichen auf dem druckbaren Ergebnis erforderlich?
Sollten Druck‑Ereignisse 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 eigentliche Regel kontextabhängig ist. Modellieren Sie das Drucken als eigene Operation, damit sie unabhängig vom Ansehen und Herunterladen autorisiert werden kann.

2. Trennen Sie UI‑Zustand von Autorisierung

Die Host‑Seite kann entscheiden, ob ein Druck‑Steuerelement angezeigt wird, nachdem sie ein anwendungsbasiertes Berechtigungsergebnis erhalten hat. Das verbessert die Klarheit für Benutzer, die nicht drucken dürfen.

Das Verbergen eines Steuerelements ist jedoch keine Autorisierungsgrenze. Ein Benutzer kann weiterhin einen bekannten Endpunkt direkt aufrufen, eine frühere Anforderung wiederholen oder das Browser‑Drucken für sichtbare Inhalte auslösen. Jeder Server‑Pfad, der druckbare Ausgabe 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 Druck‑Aktion	Autorisiere und erstelle die angeforderte Ausgabe
Drucken verweigert	Verstecke oder deaktiviere die Aktion mit einer klaren Erklärung	Gib eine „Forbidden“-Antwort zurück
Richtlinie unbekannt	Halte die Aktion deaktiviert, während die Berechtigung geladen wird	Erstelle keine Ausgabe
Sitzung abgelaufen	Bitte den Benutzer, sich erneut zu authentifizieren	Lehne die veraltete Anfrage ab

3. Schützen Sie den Druck‑Endpunkt

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

Wenn Ihre Anwendung über einen Viewer‑spezifischen Pfad druckt, anstatt ein PDF zu erzeugen, wenden Sie dieselbe Autorisierung an, bevor Sie diesen Pfad 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 wurden. Die Doconut Live‑Demos lassen Sie das unterstützte Viewer‑Verhalten beobachten, bevor Sie sich auf eine bestimmte Integration festlegen. Prüfen Sie:

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

Betrachten Sie das offizielle Beispiel als Quelle der Wahrheit. Ein plausibel klingender Property‑Name reicht nicht aus, um zu beweisen, dass der installierte Viewer ihn erkennt.

5. Handhaben Sie das Browser‑Drucken ehrlich

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. Tastatur‑Abfang‑ und druckspezifische CSS‑Regeln können das erwartete Erlebnis verbessern, sind jedoch clientseitig umgehbar.

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

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

6. Halten Sie Download, Export und Druck getrennt

Benutzer und Entwickler behandeln diese oft als einen einzigen „Read‑Only“-Schalter, doch sie repräsentieren unterschiedliche Datenflüsse:

Ansehen zeigt gerenderte Inhalte an.
Herunterladen liefert die Quelle oder eine andere gespeicherte Datei.
Exportieren erzeugt ein abgeleitetes Format.
Drucken erzeugt eine druckbare Darstellung oder löst das Browser‑Drucken aus.

Autorisiere jede Operation explizit. Ein Benutzer, der nicht drucken darf, kann dennoch herunterladen dürfen – oder umgekehrt. Ihre Symbolleiste sollte die Server‑Entscheidungen widerspiegeln, anstatt sie zu definieren.

7. Fügen Sie nützliche Audit‑Ereignisse hinzu

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

Protokollieren Sie sowohl erfolgreiche als auch verweigerte Versuche. Wenn der Druck‑Dienst eine temporäre Datei erstellt, protokollieren Sie zudem, ob deren Bereinigung abgeschlossen wurde. Halten Sie Dateipfade, Tokens, Dokumenttitel mit personenbezogenen Daten und druckbare Inhalte aus routinemäßigen Logs heraus.

8. Testen Sie über den fehlenden Button hinaus

Die Symbolleiste ist nur die erste Behauptung. Ergänzen Sie Tests für den gesamten Vorgang:

Autorisierter Benutzer

Die beabsichtigte Druck‑Aktion ist sichtbar.
Die Druck‑Anfrage schlägt für ein erlaubtes Dokument erfolgreich fehl.
Die korrekte Revision wird verwendet.
Erforderliche Markierungen erscheinen in der erzeugten Ausgabe.
Das Audit‑Ereignis zeichnet den Erfolg auf.

Nicht‑autorisierter Benutzer

Die Aktion fehlt oder ist deaktiviert.
Eine direkte Anfrage an den Druck‑Pfad liefert eine „Forbidden“-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 Druck‑Anfrage 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 prüfen. Integrationstests sollten die Richtlinien‑Auswertung und die dokumenten‑bezogene Autorisierung unabhängig verifizieren.

Häufige Fragen

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

Sollte die Druck‑Berechtigung in der Ansicht‑URL enthalten sein?
Bevorzugen Sie eine serverseitige Autorisierungsentscheidung, die an den authentifizierten Benutzer, das Dokument und die Operation gebunden ist. Falls eine temporäre Referenz Berechtigungen trägt, beschränken Sie deren Geltungsbereich, schützen Sie sie vor Logs und Referrern und validieren Sie sensible Aktionen erneut.

Reicht das Deaktivieren des Drucks für vertrauliche Dokumente aus?
Nein. Es ist nur eine Usability‑ oder Abschreckungsmaßnahme. Vertrauliche Workflows benötigen zudem Speicher‑Schutz, objektbasierte Autorisierung, kontrollierte Exporte, Aufbewahrungsregeln, Monitoring und ein akzeptiertes Restrisiko‑Modell.

Fazit

Eine vertrauenswürdige Doconut‑Drucksteuerung beginnt beim Server und endet in der Benutzeroberfläche. Definieren Sie die Richtlinie, schützen Sie die Operation, konfigurieren Sie ausschließlich die dokumentierte Option Ihrer installierten Viewer‑Version, erklären Sie das Ergebnis den Benutzern und testen Sie direkte Anfragen ebenso wie die Symbolleisten‑Sichtbarkeit. Nutzen Sie die offizielle Funktionsseite, Dokumentation, Downloads und Demos als Implementierungsquellen, anstatt Produktcode im Artikel neu zu erfinden.