Chrome Extension Kit

ARTICLE

Chrome拡張からライセンスを検証する流れ

Chrome拡張のライセンス検証リクエストと権利応答を表す図。

有料Chrome拡張のライセンス検証は、単に「キーが合っているか」を見るだけではありません。 ユーザーが購入した権利を拡張内の機能へ反映し、返金や解約、端末変更、ネットワークエラーにも耐える設計が必要です。

基本の流れは次のようになります。

  1. ユーザーがPolar.shで購入する。
  2. ユーザーがライセンスキー、または購入後の権利情報を受け取る。
  3. 拡張のOptions pageでライセンスキーを入力する。
  4. 拡張がCloudflare Workerの検証APIへキーを送る。
  5. WorkerがPolar.shまたは自前DBを確認し、有効な権利かを判断する。
  6. 拡張が検証結果を chrome.storage にキャッシュする。
  7. 有料機能を使うときにキャッシュを参照し、必要に応じて再検証する。

重要なのは、拡張から直接Polar.shの管理APIへアクセスしないことです。 管理用トークンを拡張に入れると、ユーザーへ配布されるパッケージの中に秘密情報を入れることになります。 ライセンス検証APIはCloudflare Workerなどのサーバー側に置き、拡張はそのAPIへ最小限の情報だけを送ります。

検証APIのレスポンスは、UIで使いやすい形にします。 たとえば、active、planName、expiresAt、features、checkedAt、reason のような情報を返すと、PopupやOptions pageで状態を表示しやすくなります。 ただし、サーバー側の内部IDや不要な個人情報を返す必要はありません。

ネットワークエラー時の扱いも決めておきます。 最後の検証が最近成功しているなら、短い猶予期間だけ有料機能を使えるようにする設計もあります。 一方で、長期間再検証できない場合は、読み取り専用にする、再ログインを促す、サポート導線を出すなどの処理が必要です。 この挙動はユーザー体験と不正対策のバランスで決めます。

端末制限を導入する場合は、activationの概念が必要になります。 初回検証時に端末ラベルやactivation idを発行し、次回以降はそのactivation idと一緒に検証します。 ユーザーが端末を買い替えたときに古いactivationを解除できる導線も必要です。

有料機能の分岐は、UIだけで隠すのでは不十分です。 拡張内で高価な処理や外部API利用がある場合は、サーバー側APIでも権利を確認します。 UIはユーザー体験のため、サーバー側判定は課金保護のため、と役割を分けます。

ライセンス検証は、一度作ったら終わりではありません。 Productの変更、価格変更、プラン追加、返金ポリシー変更に合わせて、検証レスポンスや拡張内の表示も更新できるようにしておくと、後から拡張を育てやすくなります。

References