チュートリアル: Doconut で印刷アクセスを制御する
8/21/2026

チュートリアル: Doconut で印刷アクセスを制御する

Doconut の印刷、アプリケーション所有の認可、ビューアコントロール、そして独自の API スニペットに依存しないテスト手順をステップバイステップで解説します。

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

制御された認可ゲートで終了するドキュメント印刷パス
制御された認可ゲートで終了するドキュメント印刷パス

インストール済みビルドでサポートされている正確なコントロールを確認するには、Doconut ドキュメントと、公式のDoconut ダウンロードページから入手できるサンプルを参照してください。無関係なバージョンや未検証の記事から設定キーやソースコードをコピーしないでください。


1. 最初に印刷ポリシーを定義する

ツールバーを変更する前に、誰がどの条件で印刷できるかを書き出してください。有用なポリシーは次のような質問に答えます。

  • すべてのビューア、特定のロール、または特定のドキュメントに対して印刷を許可しますか?
  • テナント、ケースステータス、ドキュメント分類、期限切れなどに依存しますか?
  • 印刷出力に透かしが必要ですか?
  • 印刷イベントを監査しますか?
  • ユーザーは古いドキュメントのリビジョンを印刷できますか?
  • プレビューが開いている間に権限が変更された場合、何が起こりますか?

実際のルールがコンテキスト依存である場合、単一のグローバル Boolean を避けてください。印刷を独立した操作としてモデル化し、閲覧やダウンロードとは別に認可できるようにします。

2. UI の状態と認可を分離する

ホストページは、アプリケーション所有の権限結果を受け取った後に印刷コントロールを表示するかどうかを判断できます。これにより、印刷できないユーザーに対して UI が明確になります。

ただし、コントロールを非表示にすることは認可境界ではありません。ユーザーは既知のエンドポイントを直接呼び出したり、以前のリクエストをリプレイしたり、表示中のコンテンツに対してブラウザ印刷を実行したりできます。印刷可能な出力を生成するすべてのサーバールートは同じポリシーを強制しなければなりません。

UI で使用する状態は次のとおりです。

状態ビューアの動作サーバーの動作
印刷許可サポートされている印刷アクションを表示権限を確認し、要求された出力を作成
印刷拒否アクションを非表示または無効化し、明確な説明を表示403 Forbidden を返す
ポリシー不明権限がロード中の間はアクションを利用不可に保つ出力を作成しない
セッション期限切れユーザーに再認証を促す古いリクエストを拒否

3. 印刷エンドポイントを保護する

印刷または印刷可能な出力を返すアプリケーション操作を保護してください。認可判断はテナント所属、所有権、分類、ワークフロー状態、ドキュメントリビジョンを考慮すべきです。クライアントが提供したパスやストレージ URL を受け取るのではなく、サーバー側でドキュメントを解決してください。

ビューア固有のルートを介して PDF を生成せずに印刷する場合も、同様の認可を実行した上でそのルートを呼び出すようにしてください。

4. インストール済みビューアのバージョンを設定する

サーバールールが決まったら、パッケージとサンプルファイルに同梱されている正確なオプションを使用して Doconut UI を設定します。Doconut ライブデモで、統合前にサポートされているビューア動作を確認できます。次の点を検証してください。

  1. オプションが設定される場所:サーバー構成、ビュー モデル、またはクライアント初期化。
  2. ツールバー項目を非表示にするのか、アクションを無効化するのか、生成出力に影響を与えるのか。
  3. 値がビューアインスタンス単位で適用されるか、グローバルか。
  4. 印刷とエクスポートが別々の操作として扱われているか。
  5. 更新によりオプション名やデフォルトが変更されていないか。

公式サンプルを真実の情報源として扱ってください。見た目が似ているプロパティ名だけでは、インストールされたビューアがそれを認識する証拠にはなりません。

5. ブラウザ印刷を正直に扱う

ビューア設定だけで、表示情報が決して印刷・キャプチャされないことは保証できません。ブラウザはホストページ全体を印刷でき、ユーザーはスクリーンショットや写真を撮ることも可能です。キーボード割り込みや印刷専用 CSS で体験を改善できますが、クライアント側で回避可能な対策です。

ホストページが有用な紙コピーを生成すべきでない場合、アプリケーション側で印刷専用のプレゼンテーションを用意し、プレビューを説明メッセージに差し替えることができます。この動作は Doconut の公式ビューアコントロールとは別に保ちましょう。

これを「ドキュメント保護」と表現しないでください。リスク評価で強い抑止が必要な場合は、サーバー側レンダリング、認可、制御されたエクスポート、可視透かしを使用してください。

6. ダウンロード、エクスポート、印刷を分離する

ユーザーや開発者はこれらを「読み取り専用」スイッチとしてまとめがちですが、実際には異なるデータフローです。

  • 閲覧 はレンダリングされたコンテンツを表示します。
  • ダウンロード はソースまたは別の保存ファイルを返します。
  • エクスポート は派生フォーマットを作成します。
  • 印刷 は印刷可能な表現を生成するか、ブラウザ印刷を呼び出します。

各操作を明示的に認可してください。印刷できないユーザーでもダウンロードは許可される場合やその逆もあり得ます。ツールバーはサーバーの決定を反映すべきで、サーバー側で定義すべきです。

7. 有用な監査イベントを追加する

印刷が機密である場合、ドキュメント自体をログに残さずに判断を記録します。イベントにはユーザー、テナント、ドキュメント識別子、リビジョン、ポリシー結果、タイムスタンプ、相関 ID を含められます。

成功と拒否の両方を記録してください。印刷サービスが一時ファイルを作成する場合は、クリーンアップが完了したかどうかも記録します。ファイルパス、トークン、個人情報を含むドキュメントタイトル、印刷可能なコンテンツは通常のログに残さないようにします。

8. ボタンがないことだけでテストしない

ツールバーは最初の検証ポイントに過ぎません。操作全体のテストを追加してください。

認可されたユーザー

  • 意図した印刷アクションが表示されていること。
  • 許可されたドキュメントに対して印刷リクエストが成功すること。
  • 正しいリビジョンが使用されていること。
  • 生成出力に必要なマーキングが付与されていること。
  • 監査イベントが成功を記録していること。

認可されていないユーザー

  • アクションが非表示または無効化されていること。
  • 印刷ルートへの直接リクエストが 403 Forbidden を返すこと。
  • ドキュメント ID を変更してもルールを回避できないこと。
  • 認可されたセッションからコピーした URL が不適切に再利用できないこと。
  • 拒否応答が別テナントがドキュメントを所有しているかどうかを明らかにしないこと。

状態変化

  • セッション中に権限が取り消された場合、次の印刷リクエストで適用されること。
  • 期限切れセッションでは印刷できないこと。
  • 削除または上書きされたドキュメントが制御されたエラーを返すこと。
  • 一時的な印刷出力が設定された保持ルールに従うこと。

ブラウザ自動化で可視状態とレスポンスコードを検証できます。統合テストはポリシー評価とドキュメントレベルの認可を独立して検証すべきです。

よくある質問

印刷ボタンを非表示にすれば、ブラウザの印刷ショートカットは止まりますか?
いいえ。インストールされたビューアがその動作を実装している場合に限り、意図したビューアアクションが削除されます。ブラウザ印刷や画面キャプチャは別途考慮が必要で、クライアント側コードだけで完全に防止することはできません。

印刷権限を閲覧 URL に含めるべきですか?
認証されたユーザー、ドキュメント、操作に紐付くサーバー側認可決定を優先してください。一時的な参照が権限を保持する場合は、スコープを狭くし、ログやリファラから保護し、機密操作の際に再検証してください。

機密文書に対して印刷無効化だけで十分ですか?
いいえ。これは使いやすさや抑止の一手段に過ぎません。機密ワークフローには、ストレージ保護、オブジェクトレベル認可、制御されたエクスポート、保持ポリシー、監視、残存リスクモデルの受容が必要です。

結論

信頼できる Doconut の印刷制御実装はサーバーからインターフェースまで一貫しています。ポリシーを定義し、操作を保護し、インストールされたビューアの公式オプションだけを設定し、ユーザーに結果を説明し、ツールバーの可視性だけでなく直接リクエストもテストしてください。公式機能ページ、ドキュメント、ダウンロード、デモを実装の情報源として活用し、記事内で製品コードを再構築しないようにしましょう。