HTTP Signatureをlolipopレンタルサーバーで作成
ActivityPubでPOSTするには電子署名が必要。
というエントリを書いたけど、WEBでサーバー同士でやりとりしたり、WEBサービスのAPIを利用したり、電子署名が必要なのはActivityPubに限らず。
ちらほら書いてきたように、lolipopレンタルサーバーにはperlで電子署名をする時によく使われるモジュール「Crypt::OpenSSL::RSA」がインストールされていない。
ということは。lolipopではHTTP Signatureを作ることができない「Cryptが使えないんじゃ話にならない」ということになる。
しょうがないんで、ローカルにcpanから「Crypt::OpenSSL::RSA」をインストールして、ActivityPubにPOSTする時はローカルのスクリプトを使う、という急場しのぎ。
これはこれで、投稿するのにひと手間あった方が事故も起こさなくていいかな、と思ってやってたんだけど、やっぱりサーバー上だけでやれるならラクちんなことは確か。
なもんで、グーグル先生にお願いしてみたら
「Crypt-Perl-0.38」https://metacpan.org/pod/Crypt::Perl
↑pure perlのCryptモジュールがあった。
インストール時にコンパイルが必要なモジュールはOSやファイル構成、環境に依存するけど、PurePerlというのはperlだけで作られているので、perlさえあればサーバーにそのままアップロードして使える。
さっそくダウンロードして展開。テストスクリプトで試したところ、依存関係で必要なモジュールがあったのでそいつらもダウンロードして展開。
Class-Accessor-0.51
Bytes-Random-Secure-Tiny-1.011
Convert-ASN1-0.34
Crypt-Format-0.12
（あと、たぶん以前amazonのAPIがらみでインストール済みのpure perlのDigest::SHAも必要）
当然ながら（？）これらのモジュールもpure perlなので、コンパイル不要、展開するだけで使える。
サーバーの適当なところ、例えば「lib」というディレクトリを作って展開したファイル群をアップロードするだけ。
lib/Bytes/
lib/Class/
lib/Convert/
lib/Crypt/
スクリプトで use lib 'lib'
などとやればlolipopレンタルサーバーでもCrypt RSAが使えるようになる。
いや。ぶっちゃけ。これらモジュールの作者のみなさんには大感謝。大袈裟じゃなく狂喜乱舞小躍りだった。ほんとうにありがとうございます。
マジperl使いすげー。perl話者が減ってるだろう昨今、凄腕のperl使いはワシントン条約で保護すべき存在。
使い方は「 RSAモジュールで公開鍵と秘密鍵 」とほぼ同じ。
秘密鍵を使う
my $privatekey = Crypt::Perl::RSA::Parse::private($private-pem);
公開鍵を使う
my $publickey = Crypt::Perl::RSA::Parse::public($public-pem);
Signatureを作る。
my $sign = $privatekey->sign_RS256($sign-str);
encode_base64($sign, "");
Signatureを検証する。
my $decoded = decode_base64($sign);
$publickey->verify_RS256($sign-str, $decoded);
あとは。
こうすると、思いつきから投稿放流までが直結するので、事故を起こさない自制心が必要となるです、はい。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ActivityPubを使ってFediverseにたどり着く
いや、なんのこっちゃだけど。
2023年、ツイッター亡き後の世界となった。ネット空間には祖国を奪われた難民たちで溢れかえり…というB級サイバーパンクSFの設定。
そこで再評価されることになった、実は古より存在するFediverseというネットの連合空間。ActivityPubという共通の言語で繋がるネット世界、ということになった。
てことで、「いっちょかみ」できるかなあ、とここ数日あれこれ検索しまくって試して、とりあえずmastdonで検索して仲間として検索結果に出るところまではたどり着いた。
最小限のActivityPub、いわゆるお一人様で、もちろん喋ることもフォローなどアクションをすることもできない。ただ、連合空間に顔を出した、だけなんだけど。
「mastodonなどに認識してもらえる」のがまずはゴールだったんで、ここまでやったことをメモ。
（すべてはネットで検索して得られたもので、先人たちに大感謝）
ActivityPubに参加するため用意するもの
サーバーやドメインをもっていることが前提。わたしはいつものlolipopサーバー。
どうやら以下の４つがあればActivityPubに顔を出すことはできる、っぽい。
nodeinfo(json)
サーバーの情報、でいいのかな。ここにGETでアクセスされて、ウチはactivitypubやってますよ、ユーザーは1人ですけどね、というのを返す。
{
"openRegistrations": false,
"protocols": [
"activitypub"
],
"software": {
"name": "tokoroten",
"version": "0.1.0"
},
"usage": {
"users": {
"total": 1
}
},
"version": "2.1"
}
host-meta(xml)
webfingerのURLを返す。uriは検索対象のユーザー名の文字列に置換される。
<?xml version="1.0"?>
<XRD xmlns="https://docs.oasis-open.org/ns/xri/xrd-1.0">
<Link rel="lrdd" type="application/xrd+xml" template="https://tokoroten.doncaha.net/.well-known/webfinger?resource={uri}" />
</XRD>
webfinger(json)
host-metaで得られたwebfingerのURLにGETでアクセスされるのでユーザー情報のエンドポイントを返す。
{
"subject": "acct:t2aki@tokoroten.doncha.net",
"links": [
{
"rel": "self",
"type": "application/activity+json",
"href": "https://tokoroten.doncha.net/t2aki"
}
]
}
actor(json)
webfingerで取得したユーザーのURLにアクセスするとこの情報を返す。
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1"
],
"id": "https://tokoroten.doncha.net/t2aki",
"type": "Person",
"url": "https://tokoroten.doncha.net/t2aki",
"inbox": "https://tokoroten.doncha.net/t2aki/inbox",
"outbox": "https://tokoroten.doncha.net/t2aki/outbox",
"followers": "https://tokoroten.doncha.net/t2aki/followers",
"following": "https://tokoroten.doncha.net/t2aki/following",
"name": "t2aki",
"preferredUsername": "t2aki",
"summary": "@t2aki@tokoroten.doncha.net",
"icon": {
"type": "Image",
"mediaType": "image/jpeg",
"url": "https://tokoroten.doncha.net/images/prof-image.jpg"
},
"pubKicKey": {
"id": "https://tokoroten.doncha.net/t2aki＃main-key",
"owner": "https://tokoroten.doncha.net/t2aki",
"publicKeyPem": "-----BEGIN PUBLIC KEY-----\n略==\n-----END PUBLIC KEY-----",
"type": "Key"
}
}
nodeinfoやhost-metaはわかってないまま設置。
たぶん、webfingerでユーザー情報のURLを返して、そのURLにアクセスするとユーザー情報を得ることができますよ、というやりとりがあればまずは第一関門突破だと思われる。
HTTPでリクエストの投げ合いをして相互理解を深める。WEBの基本。
と、わかったようなことを書いたけど、ここにいたるまでハマりまくった。
サイトの構成をどうすればいいのか、そもそもそこから。
結論。考える必要はまったくなかった。
ActivitiyPubはディレクトリ構造とか拘束しないというか全然関係ない。全部jsonやxmlの設定ファイルでリクエストに返答できればいいだけだった。
アクセスされて、ActivityPubを構成するファイルを返す時のヘッダは以下がMUST
Content-Type: application/activity+json; charset=utf-8
てことは動的にヘッダをつけて返答する必要があるのか、ということで、スクリプトで対応。そのために.htaccessのrewriteruleで振り分けることにした。※1
.htaccess
RewriteEngine On
RewriteCond %{QUERY_STRING} ^resource=(.*)$
RewriteRule webfinger.* script-finger%1 [L]
RewriteRule nodeinfo/2\.1$ script-nodeinfo [L]
RewriteRule host-meta$ script-hostmeta [L]
RewriteRule t2aki$ script-actor [L]
ここでのハマり。
apacheのrewriteruleはそのままだと「クエリを含まない」
fingerはresourceというクエリをつけてやってくる。そのクエリが分からないんじゃ何を求められてるのかわからない。それを解決するにはRewriteCondでクエリを判定させてやれば良い、てことにたどり着くのに2時間弱。
この先、フォローしたり投稿したりするには公開鍵秘密鍵で署名する必要があって、わたしの脳みそで理解できるレベルではない。そもそもlolipopではCrypt::OpenSSL::RSAのモジュールが使えないのでないものねだり。
手元、ローカルで作って手作業で鍵を作ってリクエストを投げる、ということを考えるしかなさそう。それもHTTPのヘッダ構成を調べる必要があって、高いハードルを見上げすぎて首を痛めるレベル。
とはいえ、せっかくだし、もう少し頑張ってみるかなあ。
※1
検索していてビックリしたのが静的ファイルだけでActivityPub実装してるかたいらっしゃった。
NetlifyとSupabaseでほぼ静的なActivityPubサーバ
今回まででとても参考になったサイト
Fediverse入門―非中央集権型SNSサーバを作ろう！
田舎の昼のサイレンbotをActivityPubで実装する(マストドンにアカウントを認識してもらう編)
ActivityPubの実装についてのメモ
本当に助かりました。多謝！！！
さっそく、ひとり言掲示板 「ところてんx10」 が役に立った、ぞ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
twitterが使えなくなった
twitterのapiが昨日あたりから死んでる。認証で弾かれて使えない状態。
ていうか。APIの仕様が変わったらしくあちこち阿鼻叫喚の様相。呆れたというかツイッターにはうんざりげんなり。
twitterは、web本棚で本棚に本を登録した時に書名をツイートしたり、本棚アカウントにリプライして、自分の本棚を検索したり、といったことで利用している・していた。
ガラケーの時に、自分の本棚を開いても、検索したりする状況で、あのチマチマした画面が使いにくくてうっとーしーったらありゃしない。なもんで、ツイッターを利用することにした。
…という経緯でもあるんで、ガラケーが終了してスマホ前提なら画面、UI的なことは、それほど問題じゃない。web本棚のツイートについて確認してみるとほぼ利用実態もない。公開しているサービスの一部を取り止めにするのは、サービスレベルの低下だろ、と言われるとごめんなさい、だけど、この際、いろいろ不明、不透明なツイッター依存は取り止めにするしかない。
PC版
スマホ版
趣味は読書2 https://doncha.net/
このWEB本棚で、ツイッターを使う、ツイッターのAPIを使ってる部分をばっさり削除してまわった。
何度も言ってる、というか何度も自画自賛するんだけど。
このWEB本棚は実によくできていて、役割分担単位でのモジュール設計のおかげで、ツイッターが絡んでるところを排除するのもスグだった。これを作った17年前の自分を褒めてあげたい。
んで、身も蓋もないことをぶっちゃけると。
このWEB本棚は「あれ？これって読んだっけ？持ってなかったっけ？」
の確認をどこでもしたいという、かなりしょぼいところが始まり。
なので、元々は「既読・未読」の分類だけ。そのほかの機能はオマケ。
読んだことさえ忘れることがあるんで、買っただけで積んでる本はまったく覚えてない。本屋さんで書棚を眺めていて、を！これは面白そうじゃん！と思って、あれ？ひょっとしてもう読んでたり買ってたりしてないか？実際、部屋には同じ本が2冊あったりするわけで。
それにはネットでアクセスできる自分の本棚が重宝する。
という自分都合でやってるということもあるからこそ、20年近くも続いてる。
ツイッターは行政なんかの公的機関も通信インフラとして使ってる。
私企業に依存してるととんでもないことになる良い例というか悪い例というか。FacebookもLINEも同じ穴のなんちゃら。
ツイッターの今の状態はとても健全とは思えないんで、政府・行政は自前、内製で使いやすい通信インフラを構築する時じゃないかな。
[06/29 12:17:18]追記
とか、のんきなコトを書いてる場合じゃなかった。
2011年11月に公開した同人誌応援サイト「創作文芸見本誌会場HappyReading」の方は、サイトを閉鎖せざるを得なかった。
Twitterアカウントでログインして本を登録するサイトなんだけど、ログインできなくなってるよ、と嫁さんに聞かされてビックリ。OAuth認証は生きてると聞いてたのに、それもダメになったのか。てことは利用しようにも利用できない状態。ほんと困った、というか弱った。なんでまたそんな根本的な部分を使えなくするんだか。
しかたがないので、トップページにお知らせを上げて、サイトの閉鎖作業。
WEB本棚の方はメールアドレスで登録、ログインすることにしてるんだけど、実はこれもあやしい、かな。メールアドレスは個人情報にあたるので本当ならPマークなんてのが必要となる、はず。ただ、このサイトを「業」としてやってない、個人の趣味の範囲だから大丈夫かなあ、と思ってるんだけど、ツッコミというか突っ込まれどころかもしれん、か。
いろいろ面倒な時代になったなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
AmazonPA-API5に移行で大騒ぎや
amazonのAPIが2020年にバージョン5になります。
https://affiliate.amazon.co.jp/help/node/topic/GZBFW3F79Y7FADBL
…というのは薄っすら意識はあったものの、1/23に届いたメールタイトルに驚愕
「IMPORTANT UPDATE -
Upgrade to PA API 5.0 before PA API 4.0 shuts down on March 9, 2020」
この「PA API 4.0 shuts down on March 9,2020」はさすがに見逃さなかった。
これまでずっと使い続けていたAPIのまさかの終了のお知らせだ。
去年2019年は、売上のないアカウントはAPIの使用制限がかかるようになり（売上のないアカウントは実質使えなくなり）困ったなあ、と思いつつも、たまーーーに、ポツリとクリック→購入があって使える日もあったんだけど、今回のAPIの変更は、そんな呑気なことを言ってるヒマはない。
まったく使えなくなるのだ。
てことで対応しなきゃまずい。とてもまずい。かなりまずい。
慌ててamazonのwebサービスドキュメントページをざっくり確認。
https://webservices.amazon.com/paapi5/documentation/
ver4とver5ではまったく違う。別人となる。
https://webservices.amazon.com/paapi5/documentation/migration-guide/whats-new-in-paapi5.html
取得するデータが、今までずっと変わらずXMLだったのに、ver5からはJSONになる！！びっくりマークをつけてもつけたりないぐらい驚天動地だ。
…てことは、現状使っている自作のスクリプトは全面的に書き換えが必要となる。
SDKを使ってお手軽に、とか思って探してみたところ、ver5に用意されているSDKは、Java、Node.js、Python、PHPの4つ。なんでperlがないねんっ！！
確かamazonはフロントのWEB側はperlだったはずだろう。今どきのWEBサービスには珍しくperlのサンプルもずっと用意してくれていたってのに、だ（残るはPaypalぐらいか）
JavaもNode.jsもわからんちんだし、Pythonもこれからの主役はこれか、ぐらいの遠巻き。
PHPがどうにか少しはいじれるので、サンプルをダウンロードして、perlに移植してみた。
サンプルに入っているDefaultApi.phpでエンドポイントやオペレーション名を拾って、WithoutSDKのサンプルコードで署名込みのヘッダーを作れるようにした。
PHPはどこからグローバルというか、スコープというのか知らんけど、把握するのにあっちこっち行かなきゃわからないから好きじゃなかったんだ、てのを再認識。
さて、これでそれっぽいリクエストを作れるようになったはずなんだけど。
売上のないアカウントなので、試せない。
売上のないアカウントには用はないamazonだ。
作ったスクリプトを使って。
ローカルのPCでリクエストを投げると
439 TooManyRequests というステータスと、JSONでエラーメッセージが返ってくる。
試しにレンタルサーバーに上げてそこからリクエスト投げると
503 とHTMLのエラーページが返ってくる。
どうやらどちらも売上のないアカウントだから相手にされない、ということっぽい。
一応、レスポンスのサンプルは公式ページにある。
でもなあ、こういうのって実際に何が返ってくるのか確認できなきゃ難しいんだよなあ。
てことで、大慌てで昨日一日ごそごそやってみた感想というか所感というかなんちゅーかほんちゅーか。
APIとかクロールとかで検索するとPython本が上位にずらーっと。
インストールぐらいしていっちょかみしといたほうがええか…。
まあ、最悪はamazonのデータを利用してサービスを公開していて安定稼働している他サイトからデータをいただくというクズなことをすれば、わたしのサービスが止まることもないんだけどね。うーむ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
書誌情報データを求めて三千里
一昨日、新元号の発表があった4月1日に国立国会図書館の書誌データAPIが解禁となった。
今までも検索などに使えていたけど、データベースとしてガツガツ使うには登録が必要だったり面倒くさかったのが、4月1日からは誰でも自由に使ってもかまわんぜ！になった。
てことで、今さら国立国会図書館の書誌データAPIをごそごそ覗いてみた。
国立国会図書館サーチについて＞API仕様の概要
https://iss.ndl.go.jp/information/api/riyou/
わたしの、というかわたしが公開しているサイトの使い方は前にも書いた通り。
「ISBNをキーにして書誌データと書影URLを取得したい」
たとえば、スティーヴン・キングの『シャイニング』
ISBNは978-4167705633
これを国立国会図書館のAPIで探すには以下
https://iss.ndl.go.jp/api/opensearch?isbn=978-4167705633
→書誌情報のXMLが返ってくる
https://iss.ndl.go.jp/api/openurl?isbn=978-4167705633
→検索結果ページが返ってくる
https://iss.ndl.go.jp/api/sru?operation=searchRetrieve&maximumRecords=10&query=isbn%3d9784167705633
→書誌情報XMLが返ってくる（このsruはさらに細かく検索方法の指定もできる）
うちの場合、必要な書誌情報はopensearchで十分。
著者についてももろもろ考慮されて（同性同名や読みなど）おり、データのクオリティは信用できる。さすが。
https://www.ndl.go.jp/jp/data/faq/author.html
蔵書のある図書館の情報なども取得できるので、位置情報と合わせて「目当ての本がある最寄りの図書館」なんて検索も実装できるし、その手のアプリがすでにあるのは、国会図書館のデータが元ネタじゃないかな。
だけど、書影がないのはほんと残念。
本棚を眺める楽しみのひとつ、というか欠かせないのが表紙だもんなあ。
基本的な書誌情報は国立国会図書館で、書影・表示画像はamazonなどのショップサイトのURLを別途取得…とか1冊の本のために2回も外部にリクエストしてるとサイトの表示がもたつく原因になってしまう。
てことで、うちのサイトのデータ取得方法は現状のままとする。
国会図書館のデータはまた何か別の用途で利用させてもらおう。しっかりとしたデータは見ていて気持ちいい（データオタク）
ちなみに。
「一般社団法人 日本出版インフラセンター」という版元主導のところも3月25日に書誌データベースのサイトをオープンしたけど、APIもなく、手入力でポチポチ検索できるだけ、なのでスルー。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
paypalを使って電子書籍のダウンロード販売
電子書籍元年が何度もきたおかげで、電子書籍(デジタルコンテンツ)のダウンロード販売がDRMもついてAmazonや楽天kobo、iBookstore、KADOKAWA☆BOOKWALKERに並べることができる時代となった。
また、電子書籍専門というわけではなく、デジタルコンテンツをダウンロード販売できるサイトも百花繚乱雨後筍で、コンテンツさえ用意できれば個人で簡単に販売ができる。
「デジタルコンテンツをダウンロード販売できるサイトを比較してみた」
https://writing-san.blog.jp/archives/32017213.html
また、ワードプレスにはダウンロード販売のためのプラグインまであって、販売チャンネルの選択肢はたくさんある。
「Easy Digital Downloads - ダウンロード販売サイトを簡単に作れるWordPressプラグイン」
https://netaone.com/wp/easy-digital-downloads/
集客力販売力、販売手数料や手間ひまを考えて自分に合うところにコンテンツを置けばいいし、そうすれば販売ページへのURLや購入ボタンをSNSや自分のサイトに貼りつけて告知できる。
ぶっちゃけ、わざわざ自分でダウンロード販売の仕組みとか作るのは時間と労力の無駄なのでオススメしない。
面白そうだ、という好奇心自己満足。それと、もしかすると、何らかの事情で他社サービスにコンテンツを置くわけにはいかないような場合に。
てことなので、以下はわたしの技術メモ。備忘録。
内容的には2010年の雑記とPayPalとのやり取りなどはほぼ同じ。
「paypalと電子書籍のダウンロード販売（その１）」
https://t2aki.doncha.net/?id=1277017233
「paypalと電子書籍のダウンロード販売（その２）」
https://t2aki.doncha.net/?id=1277130006
今回の雑記では自サバ側のこともメモしておく。
【じぶんちでの設定】
コンテンツをサーバーの所定のフォルダにアップロード。
サーバーのデータベースにコンテンツの商品登録。ここで商品にIDを付ける。
以下3つのスクリプトを用意
・ご購入ありがとうございますページのスクリプト
・IPN受信&データベース登録用のスクリプト
・ダウンロード用スクリプト
【PayPalでの購入ボタン作成・各種設定】
「トップ」→「販売ツール」のメニューにある「売り手の設定」から
→「PayPalボタン」
[今すぐ購入]サンプルボタンあたりを雛形に「ボタンの編集」で商品名や値段などを入れる。ここではオプションの商品ID（＝データベースで決められたID）を入れるのを忘れずに。
ボタンを作ったら「コードをコピー」して自分のサイトの購入ボタンを設置したいところにコードをペーストする。
→「ウェブサイトの設定」(ウェブペイメントの設定)
・ウェブペイメントの自動復帰「オン」
・復帰URL：ご購入ありがとうございますページのURLを記入
・支払いデータ転送「オン」※IDトークンをコピーしておく
・暗号化されていないウェブペイメントの受領拒否「オフ」
・PayPalアカウントオプションサービス「オン」
・連絡先電話番号「オフ」
・エクスプレスチェックアウトの設定「いいえ」
→「即時支払い通知」(IPN)
・通知URL：IPNを受信するスクリプトのURL
・メッセージの配布：有効
→「PayPalボタンの言語コード化」
・「詳細オプション」→「UTF-8」
【PayPalとのやりとり】
ユーザーの動きは以下の3つ。
1)ユーザーがオレオレサーバーの購入ボタンをクリックすると
2)PayPalの決済ページに飛んでそこでお支払い
3)お支払いが終わるとオレオレサーバーの購入ありがとうございましたページに戻ってくる。
ユーザーのお支払い終了と同時にPayPalからオレオレサーバーに購入データが飛んでくる。
購入データは以下の2種類。
データを取得して解析するためのサンプルコードがPayPalに用意されていて、そのまんま利用させてもらう。
3)PDT(Payment Data Transfer)
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・ユーザーが購入ありがとうございますページにリダイレクトされてくる時に、トランザクションを持ってアクセスしてくる
→オレオレサーバーからPayPalへ
・トランザクションと管理ページの「支払いデータ転送」の項目に記載されているIDトークン、コマンドをPOSTでPayPalにリクエスト
→PayPalからオレオレサーバーへ
・POSTした内容が正しければ一行目に「SUCCESS」と書かれたデータを返してくる
このPDTデータは
SUCCESS
first_nameJane+Doe
lst_name=Smith
payment_status=Completed
など、1行にひとつ「ネーム＝バリュー」形式、NVP形式のデータとなっている。
※ユーザーが支払いを終えて待たずにすぐブラウザを落としたりするとデータ取得できない。購入ありがとうございますページにリダイレクトされてやってきて初めてデータのやり取りが生じる。
PDTデータ取得＆解析のサブルーチン
※HTMLデコードと文字コードをutf8にしているところ以外はサンプルコードのまんま。
PDTデータのpayer_emailやitem_nameなどを「ご購入ありがとうございます」ページの「～様」や「～をご購入いただきありがとうございました」などの個別の表示に使う。
PDTデータのitem_number(商品ID)でダウンロード商品なのか、別の商品なのかを判定して、ダウンロード商品の場合はダウンロードURLを表示する。ダウンロードURLはユーザーのemailやtransactionidなど一意のものから作成している。
4)IPN(Instant Payment Notification)
ユーザーから見える言わば表側のPDTと違って、こちらは裏側。
ユーザーがお支払いを終えると管理ページで指定したURLにデータが飛んでくるので取りこぼしがない。
PDTはユーザーに見せるご購入ありがとうございますページに使う程度で、オレオレサーバーのデータベースに購入の記録を残すためにはこちら、IPNを使う。
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・購入データが送られてくる。いわゆるWEBのフォームデータで「&」で繋がれた「ネーム＝バリュー」形式
→オレオレサーバーからPayPalへ
・送られてきた購入データにコマンドをひとつつけてPayPalにPOSTする
→PayPalからオレオレサーバーへ
・「VERIFIED」か「INVALID」か一行返ってくる。これ以外は調べる必要があるらしいが滅多になさそうだし、PayPalの管理画面で確認すれば良い。
IPNデータ取得＆解析のサブルーチン
エラーはIPNのデータをつけてメールするように。
VIRIFIED(データが正しい)場合でも以下の4点を確認する。
・支払いのステータス「payment_status」が完了「Completed」であることを確認
・すでに完了した取引の悪用防止のために「txn_id」が過去のものと重複していないことを確認
・不正アカウントに支払いされないように「receiver_email」がPayPalアカウントに登録したメールアドレスであることを確認
・価格が変更されていないか確認(商品IDなども)
確認できたらオレオレサーバーのデータベースに必要情報を登録して、ユーザーにお礼とダウンロードURLを書いたメールを送信する(自分にも同じものを送信)
※データ確認の部分やメールの部分以外はサンプルコードのまんま。
【ダウンロードについて】
ダウンロードはダウンロード用のスクリプトがファイルを返すようにしてある。
たとえば、わたしが自分だけで作ったコンテンツなんかはどうでもいいんだけど、表紙が依頼原稿だったり、アンソロジーでほかの人の原稿が入っていたりするとそうもいかない。回数や期間を無制限にするわけにはいかない。
なので、ファイルの置き場所＝URLをそのままユーザーにお知らせできない。
ダウンロード用のスクリプトを噛ませて
・ダウンロードのURLは購入者ごとに違うものを作る
・ダウンロード回数を制御する
・ダウンロード期間を制御する
といったことを仕込んだ。
また、ダウンロードごとにIPやUserAgentを記録すれば、不正なアクセスやダウンロードできない事故などの問題解決にも役立つ。
以前の雑記にも書いたように、PayPalは管理ページに記録が残ってるし取引が生じたらいちいちメールも飛んでくるので、致命的な問題にはならないはず。サポートもびっくりするというか恐縮するぐらいに厚い。
残念なことに(法律的に？)日本では単純にクレジットカードだけで支払いはできなくなった(ペイパルへのアカウント・会員登録が必須となった)けど、個人での少額決済に手軽に使えるので助かるなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
