S3のエンドポイントまたはリージョンの不一致を修正する

dosyaのS3ゲートウェイはAPIホストの配下にあります。公開済みのクライアント設定では、エンドポイントhttps://api.dosya.dev/s3、公開リージョン値us-east-1、パス形式のアドレス指定、wks_…のようなワークスペースIDと同じバケット名を使います。リージョンは必須のクライアント項目に入力する値です。ゲートウェイは特定の署名リージョンを強制しません。

始める前に

親APIキーで**「S3」ゲートウェイ**を許可したS3認証情報を使ってください。ユーザーは引き続きバケットのワークスペースに所属し、ロールにS3アクセス権限が必要です。オブジェクトの一覧表示にはファイルアクセス権限も必要です。

署名リージョンはプロトコルの設定であり、アップロードしたデータの物理的な保存場所ではありません。dosyaは新しいオブジェクトをワークスペースに設定されたリージョンに保存します。クライアント向けの手順と互換性レスポンスではus-east-1を公開しています。一方、署名検証では各リクエストの認証情報スコープに記載されたリージョンとサービスから署名キーを導出します。

手順

1. シークレットを公開しないようにクライアントのプロファイルを開き、エンドポイントをhttps://api.dosya.dev/s3と1文字ずつ比較してください。
2. 公開され本番環境でテスト済みのクライアント設定にはus-east-1を使ってください。認証情報スコープと署名キーに同じ値を一貫して使っていれば、別のリージョン自体は不一致ではありません。
3. パス形式のアドレス指定を有効にし、ワークスペースのサブドメインではなく/s3/{workspace-id}/{key}の形式でリクエストを送信します。
4. バケットには表示名、スラッグ、フォルダー名ではなく、dosyaから取得した正確なワークスペースIDを設定してください。
5. 範囲を絞ったルート一覧またはHEADリクエストで再テストしてください。SignatureDoesNotMatchの場合は、シークレット、正規パス、クエリ、署名対象ヘッダー、本文ハッシュ、日付、リージョン、サービスをまとめて確認します。リージョンだけを変更しても別の署名の問題は修正されません。
6. リクエストが成功したら、許可されたテスト用プレフィックスを1つ一覧表示し、返されたキー名を確認してからクライアントの通常の処理を再開してください。

期待される結果

クライアントは実際の/s3リクエストパスに署名し、対象のワークスペースのバケットに接続します。有効な一覧にはAPIキー、メンバーのロール、任意のフォルダー起点で許可されたワークスペースとオブジェクトだけが返されます。

InvalidAccessKeyIdは不明または取り消し済みのS3アクセスIDを示します。SignatureDoesNotMatchはクライアントとゲートウェイが異なる正規リクエストまたは署名キーを計算したことを示し、us-east-1以外のリージョンが原因であることの証明にはなりません。NoSuchBucketはワークスペースIDが誤っているか、このユーザーが利用できないことを示します。

関連ガイド

• S3互換ツールで接続する
• S3アクセスの問題を解決する