公式のDoconut機能カタログでは、ブラウザ印刷とPDFエクスポートがビューアの機能として一覧されています。これらへのアクセスを制御するには、まだ2つの別個の判断が必要です:Doconutが該当アクションを表示するかどうか、そしてホストアプリケーションが現在のユーザーとドキュメントに対してその操作を許可するかどうか。

インストール済みビルドでサポートされている正確なコントロールを確認するには、Doconutドキュメントと公式のDoconutダウンロードページから入手できるパッケージサンプルから始めてください。無関係なバージョンや検証されていない記事から設定キーやソースコードをコピーしないでください。
1. 印刷ポリシーを最初に定義する
ツールバーを変更する前に、誰がどの条件で印刷できるかを書き出します。有用なポリシーは次のような質問に答えます:
- 印刷はすべてのビューア、特定のロール、または特定のドキュメントに対して許可されますか?
- 判断はテナント、ケースステータス、ドキュメントの分類、または有効期限に依存しますか?
- 印刷出力に透かしが必要ですか?
- 印刷イベントを監査すべきですか?
- ユーザーは古いドキュメントのリビジョンを印刷できますか?
- プレビューが開いている間に権限が変更された場合、何が起こるべきですか?
実際のルールが文脈依存である場合、単一のグローバルブール値を避けてください。印刷を独立した操作としてモデル化し、閲覧やダウンロードとは別に認可できるようにします。
2. UI状態と認可を分離する
ホストページは、アプリケーション所有の権限結果を受け取った後に印刷コントロールを表示するかどうかを決定できます。これにより、印刷できないユーザーに対する明確さが向上します。
ただし、コントロールを非表示にすることは認可境界ではありません。ユーザーは既知のエンドポイントを直接呼び出したり、以前のリクエストを再送したり、表示中のコンテンツでブラウザ印刷を実行したりできます。印刷可能な出力を生成するすべてのサーバールートは、同じポリシーを強制しなければなりません。
UIでは明確に区別された状態を使用してください:
| 状態 | ビューアの動作 | サーバーの動作 |
|---|---|---|
| 印刷許可 | サポートされている印刷アクションを表示 | 要求された出力を認可し生成 |
| 印刷拒否 | 明確な説明とともにアクションを非表示または無効化 | Forbiddenレスポンスを返す |
| ポリシー不明 | 権限ロード中はアクションを利用不可に保持 | 出力を生成しない |
| セッション期限切れ | ユーザーに再認証を求める | 古いリクエストを拒否 |
3. 印刷エンドポイントを保護する
印刷を呼び出す、または印刷可能な出力を返すアプリケーション操作を保護してください。認可判断はテナントメンバーシップ、所有権、分類、ワークフロー状態、ドキュメントリビジョンを考慮すべきです。クライアントが提供したパスやストレージURLを受け入れるのではなく、サーバー側でドキュメントを解決してください。
アプリケーションがPDFを生成せずにビューア固有のルートを通じて印刷する場合でも、そのルートを呼び出す前に同じ認可を適用してください。
4. インストール済みビューアバージョンを設定する
サーバールールが確立したら、バージョンに同梱されたパッケージおよびサンプルファイルで文書化されている正確なオプションを使用してDoconut UIを設定します。Doconutライブデモを利用すれば、特定の統合にコミットする前にサポートされているビューア動作を確認できます。以下を検証してください:
- オプションが設定されている場所:サーバー構成、ビュー・モデル、またはクライアント初期化。
- ツールバー項目を非表示にするか、アクションを無効化するか、生成された出力に影響するか。
- 値がビューアインスタンスごとに適用されるか、全体に適用されるか。
- 印刷とエクスポートが別々の操作かどうか。
- アップデートでオプション名またはデフォルトが変更されたかどうか。
公式サンプルを真実の情報源として扱ってください。見た目が妥当なプロパティ名だけでは、インストールされたビューアがそれを認識しているという十分な証拠にはなりません。
5. ブラウザ印刷を正直に扱う
ビューアの設定だけでは、表示された情報が印刷されたり取得されたりしないことを保証できません。ブラウザはホストページを印刷でき、ユーザーはスクリーンショットや写真を撮ることができます。キーボードのインターセプトや印刷専用の CSS は期待される体験を向上させますが、クライアント側で回避可能な手段です。
ホストページが有用な紙のコピーを生成すべきでない場合、アプリケーションは独自の印刷専用プレゼンテーションを使用して、プレビューを説明メッセージに置き換えることができます。そのホストページの挙動は Doconut の文書化されたビューア制御とは別に保ってください。
これを文書保護として説明しないでください。リスク評価でより強力な抑止が必要と判断した場合は、サーバーサイドレンダリング、認可、制御されたエクスポート、可視的な透かしを使用してください。
6. ダウンロード、エクスポート、印刷を分離する
ユーザーや開発者はこれらを「読み取り専用」スイッチとして扱うことが多いですが、実際には異なるデータフローを表しています。
- View はレンダリングされたコンテンツを表示します。
- Download はソースまたは別の保存されたファイルを返します。
- Export は派生フォーマットを作成します。
- Print は印刷可能な表現を生成するか、ブラウザ印刷を呼び出します。
各操作を明示的に認可してください。印刷できないユーザーでもダウンロードは許可されることがありますし、その逆もあり得ます。ツールバーはサーバーの決定を反映すべきであり、ツールバーが決定を定義すべきではありません。
7. 有用な監査イベントを追加する
印刷が機密である場合、文書自体をログに残さずに決定を記録してください。イベントにはユーザー、テナント、文書識別子、リビジョン、ポリシー結果、タイムスタンプ、相関 ID を含めることができます。
成功した試行と拒否された試行の両方を記録してください。印刷サービスが一時ファイルを作成する場合、そのクリーンアップが完了したかどうかも記録します。ファイルパス、トークン、個人データを含む文書タイトル、印刷可能なコンテンツは通常のログに残さないでください。
8. ボタンがないこと以上のテスト
ツールバーは最初の検証にすぎません。操作全体に対するテストを追加してください。
認可されたユーザー
- 意図された印刷アクションが表示されている。
- 許可された文書に対して印刷リクエストが成功する。
- 正しいリビジョンが使用される。
- 生成された出力に必要なマーキングが表示される。
- 監査イベントが成功を記録する。
未認可のユーザー
- アクションが存在しないか無効化されている。
- 印刷ルートへの直接リクエストは拒否されたレスポンスを返す。
- 文書 ID を変更してもルールを回避できない。
- 認可されたセッションからコピーした URL は不適切に再利用できない。
- 拒否は別のテナントが文書を所有しているかどうかを明らかにしない。
状態変化
- セッション中に権限が取り消された場合、次の印刷リクエストで強制される。
- 期限切れのセッションでは印刷できない。
- 削除または上書きされた文書は制御されたエラーを返す。
- 一時的な印刷出力は設定された保持ルールに従う。
ブラウザ自動化で可視状態とレスポンスコードを検証できます。統合テストはポリシー評価と文書レベルの認可を個別に検証すべきです。
よくある質問
印刷ボタンを隠すことでブラウザの印刷ショートカットが止まりますか?
いいえ。インストールされたビューアがその動作を実装している場合にのみ、意図されたビューア操作が削除されます。ブラウザ印刷とスクリーンキャプチャは別々に考慮する必要があり、クライアント側のコードだけで完全に防止することはできません。
閲覧 URL に印刷権限を含めるべきですか?
認証されたユーザー、文書、操作に結び付けたサーバーサイドの認可決定を優先してください。一時的な参照が権限を保持する場合は、範囲を狭くし、ログやリファラから保護し、機密操作を再検証してください。
機密文書に対して印刷を無効にするだけで十分ですか?
いいえ。これは使いやすさや抑止の一つの制御に過ぎません。機密ワークフローには、ストレージ保護、オブジェクトレベルの認可、制御されたエクスポート、保持ルール、監視、そして受容された残余リスクモデルが必要です。
結論
信頼できる Doconut の印刷制御実装はサーバー側から始まり、インターフェースで完結します。ポリシーを定義し、操作を保護し、インストールされたビューアの文書化されたオプションのみを設定し、結果をユーザーに説明し、直接リクエストとツールバーの可視性の両方をテストしてください。公式の機能ページ、ドキュメント、ダウンロード、デモを実装の情報源として使用し、記事内で製品コードを再現しないでください。