APIファイルの取得不可と権限不足を区別する

ファイルのリクエストはリソースの存在を明かさないために404を返すことがあります。そのため、ステータスだけではレコードが削除されたかどうかは証明できません。連携が正当に取得済みの識別子だけを調べてください。

各応答の意味

GET /api/files/:idでは、404 File not foundは不明または解決できないID、リクエスト元に非表示のファイル、サイトフォルダー外を指定したWordPressサイトキーに対応します。同じ応答を返すことで存在を明かしません。

解決されたファイルでも、そのワークスペースのメンバーでない場合は403 Access deniedが返ることがあります。ほかの403の本文は、You don't have access to the files page、This file is outside the folder you're confined to、構造化されたfolder_lockedの結果、ワークスペースの固定先の不一致、APIキーのスコープや利用先による拒否など、より具体的な原因を示します。

手順

1. 同じ連携に以前返されたファイルIDから始め、想定するワークスペース、フォルダー、キーを記録してください。
2. 認証情報が完全で期限切れでなく、REST APIでの使用が許可され、フォルダーに固定されていないことを確認してください。
3. キーのワークスペース固定先を既知のファイルのワークスペースと比較し、現在のメンバーが引き続き所属していることを確認してください。
4. GET /api/files/:idをリクエストし、両方を「存在しない」とまとめず、正確なステータスと機密情報を除いたエラー本文を保存してください。
5. 403では示されたスコープ、利用先、固定先、ロール、範囲制限、ロックの規則に関する問題を解決してください。404では近いIDを探る代わりに、信頼できるアプリの状態とdosyaの画面を確認してください。
6. 該当する条件を修正してから既知のIDを再試行し、プライバシー保護のための404が続く場合は、その呼び出し元には利用できないものとして扱ってください。

安全なクライアントの動作

原因を区別するために推測したfile_…の値を列挙しないでください。非表示のファイルは意図的に存在しないものとして扱われます。フォルダーに固定された通常のAPIキーは、その固定先にファイルが含まれていても、このハンドラーの前にすべてのRESTファイルリクエストで拒否されます。その認証情報の設計にはWebDAVまたはS3を使用してください。

構造化されたロック応答は、error:"folder_locked"、そのfolder_id、lock_mode:"full_lock"を含むHTTP 403です。正当なアクセス権を持つ呼び出し元にはロック解除に必要な情報を示し、非表示のファイルには引き続き404を返します。

期待される結果

クライアントは404を利用不可として扱い、権限のある担当者に403の正確な原因を示します。無関係な識別子を使って非公開データの存在を推測せず、プライバシーを保護します。

関連ガイド

• APIでファイルを一覧表示する
• APIエラーに対処する