概要
mdx Iのオブジェクトストレージに対するproxyサーバの構築に関する備忘録です。
背景
mdx Iの利用手引きにおいて、以下のように説明されています。
https://docs.mdx.jp/ja/index.html#オブジェクトストレージ
mdxが提供するS3データサービス(DDN EXAScaler S3 Data Service)で取り扱うAPI仕様を記載したDataDirect Networks社のマニュアルです。
Tipsのオブジェクトストレージの利用方法例 と合わせてご確認ください。
こちらをGoogle NotebookLMに読み込ませ、corsの実装状況について確認しました。以下が回答です。
回答
資料 でBucket CORS Featureが未実装 であることが明記されているため、EXAScaler Access S3 APIに対して、ウェブブラウザ上で動作するJavaScriptなどから直接、異なるオリジン （例えば、APIのエンドポイントとは異なるドメインで提供されているウェブサイトのJavaScript）を通してリクエストを行うと、CORS（Cross-Origin Resource Sharing）の問題が発生し、通常はリクエストがブロックされます 。
これは、ウェブブラウザのSame-Origin Policy というセキュリティ上の仕組みによるものです。異なるオリジンからのリソースへのアクセスは、サーバー側が明示的に許可しない限り制限されます。CORSは、この許可の仕組みを提供するものですが、EXAScaler Access S3においては、この機能がまだ実装されていないため、サーバー側からのCORSヘッダーなどのレスポンスがなく、ブラウザはクロスオリジンリクエストを拒否する と考えられます。
したがって、プロキシサーバー などを利用して、クライアントサイドのリクエストを一旦プロキシサーバーに送り、そこからEXAScaler Access S3 APIにリクエストを行うことで、オリジンが一致するように見せかけるなどの回避策が必要になる場合があります。プロキシサーバーは、APIからのレスポンスに必要なヘッダーを付与する役割を担うこともできます。
ただし、これはCORSの問題を回避するための一つの一般的な方法であり、他にもサーバーサイドでAPIを公開する際にオリジンを一致させるなどの方法も考えられます。重要なのは、EXAScaler Access S3 API自体がCORSの仕組みをサポートしていない ため、クライアントサイドから直接クロスオリジンリクエストを行う際には、何らかの対策が必要になるということです。
対策
理解が間違っている点もあるかもしれませんが、上記の回答から、mdx Iのオブジェクトストレージに対するproxyサーバの構築を行うこととしました。
構築したproxyサーバのリポジトリは以下です。
https://github.com/nakamura196/s3-proxy
例えば、以下で指定したバケット上のファイルにアクセスできます。
https://s3-proxy.vercel.app/public/CETEIcean.css
一方、以下が直接アクセスした例です。
https://s3ds.mdx.jp/satoru196/public/CETEIcean.css
前者では、以下のようなレスポンスヘッダーが確認でき、CORSの設定がなされていることが確認できます。
実装
Expressを用いて、以下のように実装しました。aws-sdkについては、AWS SDK for JavaScript v3に移行する必要があるようなので、この点はご注意ください。
まとめ
間違った理解をしている点もあるかもしれませんが、参考になりましたら幸いです。