S3エンドポイントとパス形式のエラーを解決する

dosyaはhttps://api.dosya.dev/s3にマウントされるため、クライアントはワークスペースのバケットをURLパスに含める必要があります。仮想ホスト形式ではホストが変わり、ゲートウェイのルートが期待するバケットのパス部分が省かれます。

始める前に

S3シークレットをスクリーンショットやログに含めないでください。ネットワーク設定を変更する前に、元のAPIキーでS3が許可され、有効期限が切れていないことを確認してください。

rcloneのS3バックエンドでは、リリース済みの動作する設定にprovider = Other、endpoint = https://api.dosya.dev/s3、force_path_style = true、region = us-east-1を使用します。テスト済みの大容量アップロードのしきい値は64Miです。

手順

1. 失敗したリクエストURLを調べ、ホストapi.dosya.dev上の/s3/{workspace-id}/{object-key}になるべきことを確認してください。
2. AWSのデフォルトエンドポイントやパスのないhttps://api.dosya.devをhttps://api.dosya.dev/s3に置き換えてください。
3. クライアントのパス形式オプションを有効にしてください。名前はツールによりforcePathStyle、s3ForcePathStyle、force_path_styleのいずれかです。
4. リージョンをus-east-1、バケットをdosyaのワークスペースIDそのものに設定してください。
5. HEADバケットまたは浅い階層の一覧を再試行してください。rcloneだけでSignatureDoesNotMatchが返る場合は、上流で書き換えられるヘッダーが署名対象にならないようsign_accept_encoding = falseを設定してください。
6. 成功したリクエストが目的のバケットに届くことを確認し、範囲を限定したオブジェクト操作を1つ実行して正確なキーを確認してください。

期待される結果

クライアントがゲートウェイの実際のパスを送信して署名し、dosyaがワークスペースをバケットとして解釈します。リクエストは無関係なAPIルートや仮想ホストではなくS3のルートに届きます。

認証がまだできない場合は、InvalidAccessKeyIdとSignatureDoesNotMatchを区別してください。前者は有効なアクセスIDが必要です。後者はシークレット、ベースパス、署名済みヘッダー、時計、クライアントの正規化を確認する必要があります。

関連ガイド

• S3クライアントを接続する
• S3の権限を制限する