PayPalで購入ボタン
購入ボタンまでは不要かな、と思ってたんだけど、宗旨替え。
ブツの通信販売と違って、電子書籍はその場でスグに欲しい。それにはやはりPayPalの「今すぐ購入」ボタンとクレジット決済だよなあ、と。
PayPalの開発環境というかテストサイトのアカウントを取得して、ごそごそテスト＆仕様確認中。テストサイト、sandbox、砂場の使い方なんかが書いてあるところを見ると、ダミーのクレジットカード番号が用意されている、とのことだったけど、わたしが確認した限り、それはなくて、自分の本当のカード番号を使わないとテストできない、のがちょっとアレな感じで嫌んだけど、モタモタしたくないんで、目をつぶる。
で、ほぼほぼサンプルコードをそのまんま使ってやってみたところ、あっさり購入ボタンの利用からクレジット決済まで実装できた…て、まだテスト環境だけ。簡単すぎて驚いた。（使ってるレンタルサーバーはlolipop。使用言語はperl）
WEBのページと同期したPDTをページ表示に使って（サンキューページみたいなもの）、非同期に送られてくる IPN のデータを lolipop の MySQL に登録。お金のやりとりは基本的に PayPal の管理ページで確認するので、DBに登録するのは最低限、誰がどのファイルを買ったのか、だけ。後はそれを元にダウンロードしてもらえるようにページを作る。
電子書籍がどーたら。
PDFなら簡単に誰でも作れる（クオリティはまた別の話として）し、おそらくEPUBという形式・規格もすぐにソフトが出揃うだろう。
なんでも同じ。問題はどうやって個人がネットで売るのか。
ほんと、なにを今さら、だろうけど、PayPalを使えば、個人がネットでクレジット決済でお金のやりとりができる、というのがスゲーんだ。何度も繰り返してくどくてすまん。眠っている原稿、塩漬けにされてる原稿があるなら、自分でネットに並べてみませんかー。業者に依頼するまでもないです。ちょっと調べるだけで自分でできます、マジで簡単ですよ。
個人レベルが勝負できる環境を作っていけるんじゃないかと思うですよ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
またり引きこもりの週末
今日は出かけることもなく、いちんち部屋でごろごろ。例によってOAuthについてググりまくりで、どうにかスクリプトも形になってきた。もたもたしてたのは、セッション管理、というか、トークンシークレットの扱いをどうするかであーだこーだしたから。結局、DBに登録することにした。もうひとつ、perlのNet：：OAuthがわたしのスキルの範囲外で手に負えなかったから。結局、OAuth部分のスクリプトを現物あわせで自作することにした。
ひっかかってたこの２点を、自前でやることにする、と決めたので、後は力仕事でガシガシ書くだけ。
せっかく、なんとなーく、OAuthについて見えてきたので、yahooとか他のOAuth窓口APIでも遊んでみようかな、とか。来年の元旦は仕事で移動もできず。部屋でのたくってることになりそうなので、スクリプト遊びする時間はたっぷりありそうだし。
久しぶりに流してみた「指輪物語」。やっぱり面白い。ガンダルフなんて棒を振り回す、ただの短気で乱暴なジジイだもんなあ。サム・ワイズ最高っす。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
token secretの保存
しかたないんで、自前でセッション管理してみることにした。ユーザーのクッキーに記録するのはIDだけ。あとはそれを見て、DB_Fileに記録したaccess token と token_secret を引っ張り出す。
twitterの OAuth で使うtokenは永続性がある＝ずーっと使えるって話だからこんな面倒なことになるのだ。その場限りなら、ユーザーのクッキーだけでもまあギリギリOKだろうと思ったんだけど、ずっと使えるトークンだと、ユーザーのブラウザのクッキーに記録させるのはちょっと怖いじゃないか。で、ずっと使えるのに、クッキーをその場限りにしておいて、いちいちアクセスさせるとAPI制限に引っかかりそうだし。
てことでコードを書くだけ書いた。それでも、これでも、やっぱり。面倒くさいだけのOAuth使うヒマがあったら、Basic認証でイケよ、どうせセキュリティ的には目くそ鼻くそだぜ、と思う自分がいて、モチベーションが上がらないまま、週末なのですでに赤ワイン。
とはいえ、yahooとかmixiとかgoogleとか、OAuthで繋ぐサービスがあるから、調べておいて損はない、はずだよなぁ。
ちなみに縦書きtwitter、「たてたったー」は、まだBasic認証です。
[12/27 16:26:52]
哀しいほどハマったので、メモ。 perl の Net::OAuthは、わたしには手におえないことがわかった。ちょろっと改造しようにも、オブジェクト指向とやらで、わたしのスキルではソースを追えない。ので、OAuthも自前で作った。そこでのハマりのメモ。
その１．
署名は、メソッド（GETとかPOST）、リクエスト先のURL（パラメータは入れない）、URLにくっつけるパラメータ。の３種類を合わせて元になる文字列を作る。このとき、各々URLエンコードが必要なのだが、ハマったのがURLにくっつけるパラメータ。
key=value＆key=value形式でvalueをURLエンコードするのはいいんだけど、一度URLエンコードした上で＆で繋いでひとつの文字列にしたら、さらに全体をURLエンコードをする必要があった。2重にURLエンコードするような感じ。
その２．
署名に使うシークレットキーは、コンシューマーキーとアクセストークンのシークレットキーがある。twitterの場合なのかHMAC-SHA1の場合なのか調べてないのだが、アクセストークンを取得するまでは、当然ながらコンシューマーキーしか手元にはない。
形式は各々URLエンコードして＆で繋いで、それをキーに使用する。
コンシューマーシークレット＆アクセストークンシークレット
まだアクセストークンのないフェーズでも＆が必要だった。
「コンシューマーシークレット＆」というケツに＆をつけてキーにする。
https://developer.yahoo.co.jp/other/oauth/api.html
https://developer.yahoo.co.jp/other/oauth/signinrequest.html
さすが yahoo！実例が載っていて大助かりだった。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
OAuth で twitter にアクセス
OAuthをごそごそやってたのは twitter がそのうち Basic認証じゃなくて OAuthをAPIのクチにする、というの読んだから。
OAuthのわかりやすい解説は他の有用なサイトにまかせるとして、素人のわたしの理解をメモる。
やろうとしているコト。
現状。
1)縦書きtwitter（わたしの作ったtwitterを利用するサイト）がある。
2)縦書きtwitterは現状ではユーザーにtwitterのIDとPASSを入力してもらって、そのユーザーのタイムラインを取得、表示している。
※入力してもらった情報はユーザーのクッキーに保存。twitterに対してはBasic認証で繋いでいる。
この（2）の部分を、今後twitterが推奨するという、OAuthでの認証にしてみたい。
ざっくり大雑把な理解で流すけど。
1)縦書きtwitterにユーザーがアクセスする。
2)縦書きtwitterは、twitter本体に対して、縦書きtwitterは登録してありますよ、とお伺いをたてる。
3)twitter本体が、おう、お前久しぶりやな、ということがわかれば、ユーザーをこっちに寄こしなさい、ということで、ユーザーを twitterにリダイレクトする。
4)ユーザーは twitter に飛ばされて、そこでIDとPASSを入力して「承認」すると、ふたたび縦書きtwitterに戻される。
5)ユーザーは、twitterからもらう アクセスのためのtoken （IDみたいなもんだ）と、tokenを含めたアクセスを正しく認識するためのtoken_secret（パスワードみたいなもんだ）を持って戻ってくることになる。
6)縦書きtwitterは、ユーザーのtokenとtoken_secret＝IDとパスワードをどこかに保存しておいて、ユーザーに縦書きtwitterを使ってもらう。
※保存するのはたぶんクッキー。DBに保存したら、今度はそのIDとPASSがだれのものか、というログインが必要になるしねえ。
一応、OAuthで TL を取得したり、つぶやきを投稿したりできるようにはしたけど。はたして、これ、本当に安心で便利なシロモノなのか、そこんとこがまるで理解できない。
Basic認証は、IDもパスワードも平文で流れるのでセキュリティに問題があるのはよくわかる、けど。Basic認証にしろ、OAuthにしろ、少なくともアクセスしている間は、IDとパスワードをどこかに保存しなきゃいけない。この穴はBasic認証だろうとOAuthだろうと同じじゃないのか。見えないIFrameに仕込まれる程度のチャチなクッキー引っこ抜きに引っかかって「なりすまし」被害に合うのは防げない、ような気がする。
ユーザーにしてみれば、yhooなりmixiなり、ひとつのIDとパスワードを使いまわしできるので管理がラク、ってだけだったら（セキュリティ的に画期的になにかが変わったわけでもなさそうな）OAuthなんてこんな「ややこしい」手順を踏まなきゃいけないメリットは感じないんだよなあ。
OAuthの良さを誰か教えてくだされ～。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
OAuthでハマったのでメモ
twitter の OAuth認証を、と思ってごそごそ調べては試行錯誤。OAuthの一次情報、仕様を見ながら、自分でサインを作ればこんなにハマらなかったと思うんだけど、ラクしようと思って、perl の Net::OAuth ver0.20に投げたのが始まりだ。
以下のページを参考にさせていただいて、CPANからOAuthをインストールすればラクショーっぽいぞ、と。
https://blog.photoble.net/archives/category/memo/oauthtwitter
https://sayama-yuki.cocolog-nifty.com/blog/2009/09/twitteroauth-d7.html
甘かった。
その１．最初のリクエストで oauth_callback_confirmed が返ってこない
その２．twitterから、リダイレクトされて戻ってきたときには 401。認証されず、 oauth_verifier も返ってこない。
なんじゃそりゃ、と。延々ググりまくって今朝未明まで。今日も天気だというのに早起きして、ググる。…ヒットしないんだけど、どうやら OAuthの 1.0 と 1.0a の違いが原因っぽい。oauth_callback_confirmed も oauth_verifier も 1.0a から導入されたパラメータ、てことだ。OAuthで作られるパラメータを確認してみると、指定しているにも関わらず、callbackが入っていない。
Net/OAuth/で grep してみて OAuth.pm を読んでようやく解決。
request パラメータを組み立てるところに
一行入れるだけ、だった。
↑これが正しいリクエストヘッダー
CPANは便利なんだけど、素人芸の、ブラックボックス、コピペ使いは限界があるんだよなあ。
ここが通ったら次はアクセストークン取得でそれの扱いをどうするのか、またググる、か。でも気力体力が尽きたので以下次号だ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
perl パズル
縦書きtwitterを眺めると、全角にしてタテに並べるURLがうっとーしー。除去するのは簡単だけど、twitterの性格上、リンクは必需品なので、どうにかできないものか、と。
記入されているのがURLだったら、それを削除して別エリアにリンクを表示させたい。
最初、push だけで、イケんじゃないかと思ったら甘かった。pushの返り値、配列の要素の数が入ってしまう。なので、無意味な sprintf を噛ませてみた。なんか不恰好だけど、欲しい結果が得られるので良しとするか。…うううむ、やっぱかっちょわりいなあ。
て、まわりくどい阿呆だった。
これだけでOK
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
