オンラインコンテンツのダウンロードページの作り方（２）
Silicon Valley Super Ware
2020年9月21日
オンラインコンテンツのダウンロードページの作り方（２）
オンラインで決済を行った後にオンラインコンテンツのダウンロードページをどのように実装するかは、販売サイトを作る上での課題の一つです。前回は、サーバ側でレンダリングする方法を紹介しました。今日は、クライアント（ブラウザー）側でダウンロードページを作る方法を紹介します。
クライアント側でやった方が楽な場合が多い！
もちろん、NextやNuxtなどを使って実装している場合は、前回のような方法ではなく、
NextやNuxtを使ってサーバー側でダウンロードページを準備するのも一つの方法です。
シンプルに実装する場合は、前回のような、1ページだけのレンダリングの実装は一つの方法ですが、やはり楽なのはReactやVueを使ってクライアント側でページを用意する方法が楽です。
クライアント側で行う方法はいくつか考えられます：
- 全てをクライアント側で実装する方法
- URLの取得をバックエンドで行う方法
簡単なのは、すべてをクライアント側で処理してしまう方法です。
最初に、URLのクエリーパラメータのセッションIDを読み取って、Firebaseのデータベースからセッション情報と商品情報を取得して、URLを生成すればOKです。
セッションIDは、Vueの場合は、「created()」で以下のように取得できます。
created() {
const sessionId = this.$route.query.session_id;
},
全てをクライアント側で処理する場合、Cloud FirestoreのデータベースとStorageの読み込みのためのアクセスをフロントエンド側に与える必要があります。
もう一つ、期限付きのURLはフロントエンドでは生成できません。（バックエンドでの処理が必要になります）
フロントエンドで全部やる場合は、固定リンクを使う必要があります
しかも、処理の過程のプログラムをブラウザーで見る事ができるので、悪意がある人がサイトのJavaScriptを見ると、決済をしていない人でもコンテンツを取得する事が可能になってしまいます。
そこで、URLはバックエンドで生成してもらうという方法の方がより安全に運用できます。
created():void {
const sessionId: string | (string | null)[] = this.$route.query.session_id;
if (sessionId) {
// Request a signed link from the backend
axios
.post("/getlink", {
sessionId: sessionId,
})
.then((res:AxiosResponse) => {
this.url = res.data.url;
})
.catch((error:any) => {
this.error = true;
});
}
},
セッションIDをバックエンドに渡せば、バックエンドがURLを生成して返してくれます。
セキュリティルールが変わってくる！
この２つの実装方法の違いは、セキュリティルールです！フロントエンドで全て処理する場合には、データベースとStorage共にクライアント側に読み込み許可を与えないとできません。
バックエンドに任せる場合、フロント側はデータベースやストレージにアクセスする事はないので、読み込みの許可は「禁止」で良い事になります。
これが大きな違いです。セキュリティールールで読み込み禁止にしておけば、ブラウザーからJavaScriptのコードを見てもデータベースへのアクセスはできません。
セッションIDも決済の際にStripeが発行するだけなので、これを他の人が取得できる可能性は低くなります。したがってリンクの取得は決済を行った人以外は難しくなります。
ちょっとした実装の違いですがサービスのセキュリティは大きく変わります！
バックエンドと連携する事でより安全なサービスが作れます！
この例からもお分かりの様に、機能の実装自体はフロントエンドだけでも出来る場合が殆どです。しかし、サービスのセキュリティを考えると、バックエンドを上手く使った方が、セキュリティの高いサービスが実現できる事多くなります。
Firebaseを利用して、実装する場合、フロントエンドからのアクセス中心で実装する事が多くなりますが、その場合はセキュリティルールを上手く設定する事が重要です。
セキュリティルールを書くのが面倒な場合は、バックエンドにアクセスを代行させた方が、簡単なルールでセキュリティを確保しやすくなります。
バックエンドでやれば安全という事ではありません
ここで、勘違いしないで頂きたいのは、バックエンドならば安全という意味ではない事です。バックエンドのアクセスに必要な情報を上手く組み合わせる必要があるという事を忘れないでください。今回の例では決済のセッションIDです。これは、決済を行った人以外は入手が困難な情報なのでセキュリティ確保に利用できます。
そのほかの例では、ログインした情報とそのセッションを利用すれば、ログインしていない人はバックエンドのアクセスを拒否するように作る事ができます。
バックエンドを使うのに必要な情報を上手く選ぶことがセキュリティの高いサービスを作る基本です。そうした事を考えながらシステムを設計します！
興味のある方は今すぐお問合せください！
またよろしければ、ニュースレターの登録をお願いします！大体週一回お届けしています。ブログよりは一歩踏み込んだもっと濃い内容を発信しています。
コメント
コメントを投稿