暴飲暴食、だな
大晦日だというのに胃が死んでるし。
昨日は、鰻に熱燗、焼肉にビール、地元飲み屋でレバーパテなどもりもり食いながら濁り酒にホッピー、焼酎、帰ってから加賀鳶。コタツで失神状態となる。
今朝は目が覚めたら胃のあたりだけじゃなく、背中側までシクシク痛むテイタラクで、昼過ぎまで布団から出るに出られず、だ。飲んだ量だけじゃなく、食った量もかなり多かったようで。
明日は仕事だし、今日はおとなしく過ごす、かなぁ。
てことで、良いお年を。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
今年もあと一日なので振り返り、だ。
ウチのポンコツサーバーの 読書SNS「趣味は読書。」 につけてきた記録を見ると、やっぱり今年も100冊行かなかった。そんなしょぼい冊数なんだけど、どうやら今年はわたし的には充実の豊作だった、かも。もちろん、ブックオフと図書館が中心なので、世間さまの新刊ランキングとはかけ離れる俺さまらキングなんだけど。
ダントツのランキングナンバー１は、一月に読んだ古処誠二「ルール」。問答無用。古処誠二の「七月七日」とこの「ルール」は義務教育の教科書に入れろよ。ひとの高潔とか尊厳とか死語になりかかっているけど死語にしちゃいけない単語を痛いほど思い知らされる傑作。古処誠二の「ルール」を読んでなにも思わない人間とは席を同じくしたくはない、絶対、ゲンミツに。てぐらい、だな。
で、今年は自分にとっての初の作家さんの豊漁。
何を今さらの上橋菜穂子を筆頭に、小川洋子、伊坂幸太郎、横山秀夫、中島らもは当たりで、はずしたのは貫井徳郎、荻原浩。５勝２敗はけっこうな勝率だろう。勘がさえた一年だったかもしれない。
既読の作家では宮部みゆきの「今夜は眠れない」とかマイク・レズニック「パラダイス」とかマイケル・ムアコックのルーンやエルリックとか、藤沢周平の用心棒日月抄とかかなりの確率で当たりを引いた幸運な一年だった。
まだ明日一日あるけど、今年の総括。面白いものをたくさん読めて、素直にありがとう、な一年だった。来年もたくさん面白いものを読みたいと願いつつ、年末年始の酒びたりの日に落ちていきます。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
年賀状
とりあえず書いた。去年、おのれの字のあまりの汚さにのけぞり、今年は「字を書く」ということで、モレスキンの手帳に毎日アレコレ書くように心がけて、今日というこの日に備えたわけだが。
相変わらず、というか去年よりさらにというか、字が汚くてがっかりだ。
だいたい。年賀状を必要とするひとたちは、それなりの年齢で字もきれいなので敗北感。日ペンの美子ちゃんなんていまどきは流行らんだろなあ。どっかからテキトーなテンプレート拾ってきて、来年はプリントアウトの年賀状にするかな。
縦書き表示twitterをOAuth版に差し替え…たのはいいけど、ググっても仕様書が見つからず。パラメータの渡し方がよくわからない。
count とか、max_id、since_idが渡せないっぽい。どうなってんだ。
[12/29 22:15:49]
嘲笑吐血レベルの低脳jさ加減だ、おれ。
count とか max_id なんてのは uri に入れるもので、authorizasionのheaderに入れちゃいけない。なので、無造作に全部headerに入れてたところを、headerに入れるべき oauth_ なパラメータと、uri に ? でつなげるパラメータに分けたところ、意図どおり、となった。
今回、例によって、というか安直にコピペしすぎたなあ。
てことで OAuth窓口の縦書き表示twitter「たてたったー」は貧弱な機能ながら、格好がついた。
» ローカル環境で電子書籍を作る、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」
