Webhookペイロードのバージョンを扱う
現在のバージョン番号のないWebhookエンベロープをイベントの種類ごとに検証し、ファイルのバージョンとスキーマのバージョンを区別して、追加項目を安全に受け入れます。
最終確認日
スクリーンショットは英語版の画面です。
現在のdosya Webhookエンベロープにはスキーマのバージョン項目がありません。安定した外側の構造はid、type、created、workspace_id、dataです。アップロードのdata.versionはファイルのバージョンであり、ペイロードのスキーマのバージョンではありません。
手順
- 生のリクエスト本文に対する署名を検証してJSONを解析し、最上位に文字列の
id、対応するtype、数値のcreated、文字列のworkspace_id、オブジェクトのdataがあることを確認します。 - 現在のイベントの種類である
file.uploaded、file.deleted、share.accessedのみを受け付けます。不正または未対応の入力はスキーマを推測せず、永続的な隔離先に送ってください。イベントIDは最上位のidが検証に通った場合にのみ付け、それ以外は受信側で生成したトレースIDを記録します。 file.uploadedではfile_id、name、バイト単位のsize、nullを取り得るfolder_id、整数のversion、真偽値のis_new_versionを検証します。そのバージョンは指定されたファイルの改訂順序にのみ使用してください。file.deletedではfile_id、name、真偽値のpermanentを検証します。ゴミ箱への移動ではfalse、ファイルまたはフォルダーの完全消去では消去されたファイルごとにtrueが送られます。share.accessedではshare_id、機密性のあるtoken、accessed_at、view、download、download_allのいずれかのaccess_typeを必須にします。バンドルのviewではfile_idとfolder_idがどちらもnullになることがあります。全体で一律に必須とせず、そのアクセスの種類で許可される識別子を検証してください。トークンを診断情報に記録しないでください。- 受信側に不要な追加項目は無視し、追加プロパティを1つ含む例と必須プロパティが1つ欠けた例でテストします。追加項目を含む例は処理され、不正な入力は部分的な副作用を起こさず、確認できる形で隔離される必要があります。
現在は振り分けに使用するスキーマのバージョンがないため、payload.versionを必須とするコードは有効なdosyaイベントをすべて拒否します。typeで処理を分け、将来の仕様を意図的に追加できるようイベント固有の検証を分離してください。
期待される結果
現在のペイロードは種類ごとの検証に通り、追加プロパティによって処理が止まることはなく、data.versionはファイルの改訂番号として扱われます。不正なイベントは共有トークンを漏らしたり処理を部分的に適用したりせず、確認できる形で失敗します。
すべてのペイロードで不明なバージョンが報告されます。 最上位のスキーマバージョンを必須とする条件を取り除いてください。現在の実装はその項目を送信しません。
新しい項目があると拒否されます。 オブジェクト全体の厳密な一致ではなく必須項目の検証に変更し、受信側が使用する項目の型チェックは維持してください。
関連ガイド
この記事は役に立ちましたか？
評価の結果を読み込んでいます…
投票すると、回答を変更できるように、必要な投票用Cookieが最長180日間保存されます。
質問と回答
このガイドの手順について質問できます。質問は確認後に公開されます。
公開の質問には、アカウントの詳細、認証情報、非公開ファイルを含めないでください。これらについては 非公開サポート をご利用ください。
質問を読み込んでいます…
dosyaアカウントにサインインすると、質問を投稿できます。