ｰ開発中ｰACTIVE

製品版プラグイン　鍵のかけ方

うむ、これは手順書化した方がいい★
Gumroad公式を現行仕様で確認してきた。今回の「1購入＝1サイト」の軽量戸締まりは、GumroadのLicense Keyとusesを使えば組める。重要なのは、Gumroad自身が1サイト制限をしてくれるわけではなく、Kaia側がusesを見て制御すること。Gumroad公式も「enforcementはcreator側」と明記してる。(Gumroad)

Planet投入用ならこれでいける。

Gumroad One-License / One-Site Lock Rule

Purpose: Kaia Specの買い切りWordPress製品について、通常利用者に対して「1購入ライセンスキー＝1サイト」の軽量な利用制限を設ける。

Table of contents

1. Scope

これは強固なDRMではない。

目的は、購入者が同じZIPと同じLicense Keyを別サイトへそのまま持っていき、通常のWordPress操作だけで複数サイト利用することを防ぐこと。

コード改変・DB直接編集など、意図的な技術的回避への完全対抗は目的としない。

2. Gumroad側の準備

対象商品でLicense Keyを有効にする。

Gumroadの商品Content編集画面から、

Insert → License key

を追加する。

ここに表示される対象商品のProduct IDを取得する。

2023-01-09以降に作成された商品では、License Verify APIにproduct_idが必要。

顧客にはGumroadがLicense Keyを発行する。

顧客は購入メール、ダウンロードページ等からLicense Keyを取得できる。

3. WordPress側のActivation UI

未認証状態では、Kaia製品の管理画面に最低限のLicense Activation UIを表示する。

必要要素：

  • License Key入力欄
  • Activateボタン
  • 成功／失敗表示

認証後は完全なLicense Keyを画面へ再表示しない。

表示例：

License: Active

4. Activation — Step A

ユーザーがActivateを押したら、まずGumroad License Verify APIへ確認だけ行う。

Endpoint:

POST https://api.gumroad.com/v2/licenses/verify

Parameters:

product_id

license_key

increment_uses_count=false

最初から使用回数を増やしてはいけない。

Gumroadはincrement_uses_countを省略するとデフォルトで使用回数を増やすため、事前確認では必ずfalseを明示する。

5. Activation — Step B

API結果を確認する。

最低限確認：

  • success == true
  • 対象Product IDが正しい
  • uses == 0
  • refunded == false
  • disputed == false
  • chargebacked == false

条件を満たさない場合はActivationしない。

uses >= 1の場合：

このLicense Keyは既に使用されている

として拒否する。

サイト移転の場合はKaia Specへ問い合わせるよう案内する。

6. Activation — Step C

未使用で正常なLicense Keyだった場合のみ、もう一度Verify APIを呼ぶ。

今度は：

increment_uses_count=true

とする。

Gumroadのusesが1増える。

成功し、返却されたusesが想定どおりになったことを確認してからローカルActivationを確定する。

7. Local Activation State

WordPress側には最低限、

  • Activated状態
  • 対象Product
  • 現在サイトのSite Identity

を保存する。

Activation後の通常アクセスでGumroad APIを毎回呼ばない。

License Keyそのものも、Activation後の常時保存が不要なら保存しない。

8. Site Identity

Activation時のWordPressサイトを識別できる値を保存する。

現在サイトと保存済みSite Identityが一致している場合：

→ Activated

DBを別サイトへコピーする等してSite Identityが変わった場合：

→ Activated扱いにしない

→ 再Activationを要求

これにより、一般的な「WPサイト丸ごと複製」でActivation状態までコピーされるケースも軽く防ぐ。

Site Identityの具体的な正規化方式は実装時に固定し、製品間で共通LEGO化する。

9. Normal Runtime

一度正常Activationされたサイトでは、

ページ表示のたびにincrement_uses_count=trueを送らない。

Gumroad公式仕様では、License Verifyは指定しなければusesを増加させるため、単なる確認処理で誤って使用回数を増やさないこと。

10. Second Site

同じZIPとLicense Keyを別のWordPressサイトへインストールした場合：

新サイトにはローカルActivationがない。

↓

License Key入力

↓

increment_uses_count=false

↓

Gumroad response:

uses >= 1

↓

Activation拒否

表示例：

This license is already in use on another site.

If you are moving your site, please contact Kaia Spec for a license transfer.

11. License Transfer

正規のサイト移転では、新しいLicense Keyを発行し直すことを基本動作にしない。

顧客から：

  • 購入時EmailまたはLicense Key
  • 旧サイトURL
  • 新サイトURL

を確認する。

Kaia Spec側で購入を確認する。

Gumroad Sales Dashboardから対象購入を開き、License KeyのUsesをResetして0へ戻す。

その後、新サイトで同じLicense KeyをActivationしてもらう。

Gumroad公式ではUsesをResetして0へ戻すことができ、±1または任意値への編集も可能。

この運用を License Transfer / ライセンス移転 と呼ぶ。

12. Failure Handling

Gumroad APIに接続できない：

→ 使用済み扱いにしない。

→ Activation失敗／通信失敗として再試行を案内。

Invalid License：

→ Activationしない。

Used License：

→ Activationしない。

Refunded / disputed / chargebacked：

→ Activationしない。

APIエラーを「ライセンス使用済み」と誤認しない。

13. WordPress Safety

Activation処理にはWordPress標準の管理者権限確認とnonceを使用する。

API通信にはWordPress HTTP APIを使用する。

License Keyをログへ不用意に出力しない。

HTMLへ完全なLicense Keyを再出力しない。

Kaia Spec独自サーバーへLicense Key・購入Email・サイトURLを送信する仕組みは、この方式には不要。

GumroadとのLicense Verify通信だけで成立させる。

14. Pre-release Test

製品化前に最低限以下を実機確認する。

  1. 未使用の正規Key → 1サイト目Activation成功
  2. 管理画面Reload → Active維持
  3. Plugin deactivate → reactivate → Active維持
  4. 同じKeyを2サイト目へ入力 → 拒否
  5. 不正Key → 拒否
  6. Gumroad通信失敗 → 誤ってUsesを消費しない
  7. Gumroad Uses Reset → 新サイトでActivation成功
  8. Site Identity変更 → ローカルActivationを引き継がない
  9. Counter既存データ・Refill・Stock等へ影響なし

15. Reuse / LEGO Boundary

この仕組みはCounter固有コードに埋め込まない。

Gumroad One-License / One-Site Lockとして切り出せる構造を維持する。

製品ごとに交換する値は原則：

  • Product ID
  • Product name / slug
  • 表示文言

その他のActivation、Uses確認、Site Identity、Transfer前提、エラー処理は共通LEGO候補とする。

Counter Standardで実機検証後、Timestamp Standard、Serial Standard等へ再利用する。

これ、公式仕様との対応もかなり綺麗。GumroadはLicense Keyの検証、usesのカウント、返金・紛争状態などを返せるし、Usesは販売管理画面からResetできる。(Gumroad)

一点だけ実装前に決め打ちしない方がいい箇所がある。Site Identityの正規化だな。https/http変更、www有無、サブディレクトリ型WPなどを「同じサイト」とする境界は、RCへ封入するときに実物を見ながら一回決める。ここを手順書で適当に固定すると、後で正規ユーザーを自分の罠に引っ掛けるｗ

あと、これを実装するにはCounter Standardの商品用Gumroad Product IDが必要。これはLicense Keyブロックの商品編集画面に表示される。(Gumroad)

Gumroad公式：License keys

というわけで、Planetにはこれを製品横断LEGO候補の手順書として置いていいと思う。Counterで実機通ったら「候補」を外して実証済みにできる★

WP　サイト、HPリンクの別窓設定方法Prev

PDF OPNext

Comment

  1. No comments yet.

  1. No trackbacks yet.

PAGE TOP
Table of contents