1  mixi2gmail

去年に書き直した、mixiの日記を取得してgmailアカウントにメールとして送信するツール mixi2gmail が最新の gmail で表示がおかしくなっていたのだが、時間がとれずに放置していたら たださんが修正してくださった。ありがたい。最新版は以下の CodeRepos.org よりどうぞ。

http://svn.coderepos.org/share/lang/ruby/mixi2gmail/

と言いつつ、法事のために日本に来る必要があったりして未だに試せてもいないのであるが…。

1  mixi2gmail

少し前から mixi のちょこちょこした変更もあって以前書いたmixi2gmail.rb の挙動が怪しくなっていたので、WWW::Mechanize 0.7.5 への対応も兼ねてコードを書き直した。最近のバージョンでは取得結果を Hpricot::Doc で返すようになり、XPath での検索も出来るようなので、以前の正規表現で切り出す形から XPath で抜き出す形に変更。画像の扱いもHTMLの中にインラインで表示されるよう、mixiアルバム画像貼り付けへの対応も含めて少しマシにした。
また Mechanize が Net::* を上書きする挙動も無くなったようなので、ちゃんとNet::SMTP を使って送信する形に書き換えた。数日試したが、ちゃんと動いているっぽいので公開。(最新版はCodeReposより)

• http://svn.coderepos.org/share/lang/ruby/mixi2gmail/
• mixi2gmail.rb

挙動としては、基本的に Linux 前提で、~/.mixi/mixirc に幾つか設定を入れて実行すると、友達の日記を画像を含めて(添付として)指定したメールアドレスに 1日記 1 HTML メールとして送信する。次回実行は新しいものだけを対象にし、また除外リスト、ウォッチリストなどの設定も出来る。

WWW::Mechanize は以前にも書いたが、ログインが必要なウェブサービスからコンテンツを持ってくるなんて言う用途には手軽で便利だ。Hpricot は Htree を改良したっぽいコンセプトだが、そこそこ高速になっているし、non well-formed な HTML 相手に Xpath や css 指定が出来るのは便利。

この手の小物は trac を直してそっちで公開したいが、どうも腰が重い。

2  (追記ないし注意書)

初回挙動は new_friend_diary にいる全ユーザの list_diary から全日記を引っ張るので処理が相当長くなってしまう。時間が長すぎると、メモリを圧迫したり、画像取得に失敗する可能性がある。
動作としては ~/.mixi/lastid.log にある数字より大きい view_diary.pl?id=.... の id の日記のみ取るようになるので、初回も適当な数字を入れておくのが無難かも…。ファイルが無いとエラーになるのはとりあえず 0 入れておいた。

ちなみにこういう挙動にしたのは、以前 mixi が new_friend_diary に 1ユーザ 1日記しか載せなかった期間があった(ので単純にそこから取ると2個以上書いているユーザの日記で取りこぼしが発生した)からなので、現状では挙動変えてもいいかもなと思わないでもないんだけど、初回以外は問題でないだろうしなぁ。

3  再追記: たださんからもらったpatchを適用

たださんがpatchを作って送ってくれたので適用しました。テスト足りてなくてすいません。頂いたメールを引用すると以下のような変更・修正になってます。

• rubygems対応 (Mechanaizeをgemで入れてる人向け)
• lastid.logの初期値対応
• HTTP_PROXY対応
• 空のexcludelistとwatchlist対応

他にも幾つかコメント頂いたんだけど、近いうちに coderepos に置いておくのでその後追々。

4  再追記: 日記トップ画像を1つしかfetchしない問題のfix

T/O。XPath の指定をミスってました。

5  再追記: GmailのMultipart取扱い変更への対応とCoderepos.orgへの移動

たださんの修正を受けた最新コードをCodeReposに移動

http://svn.coderepos.org/share/lang/ruby/mixi2gmail/

1  mixi の html/css リニューアルと mixi2gmail.rb のアップデート

予告されていたとおり、mixi の html/css が今日付けで大幅に更新された。私の回りでは概ね不評のようだが、table を駆使したレイアウトだったのが xhtml 的にだいぶましになったのはよいことじゃないかな (と言いつつ well-formed ですらないけど)。そこかしこに id が設定してあるので xpath での scrape は楽になったと思う。不満がある人は user css なりで勝手にレイアウトしなおすのがいいのかも。w3m で見難くなったのは個人的には辛い所だけど、直接アクセスする機会はそう多くないのでまぁいい。

例によって mixi日記→Gmail が動かなくなっていたので、parse 部分だけ改変した mixi2gmail.rb を置いとく。html が比較的素直なので20分くらいの作業で済んだ。10月1日深夜の html で動くのを確認。Trac 直さないとな。

ちなみに Plagger は WWW::Mixi::Scraper と CustomFeed::MixiScraper の組み合わせで使うのがいいらしい。

1  mixi、画像が外部のWebサイトで表示される仕様を修正

mixi が仕様変更で日記等の画像が外部から見えないようにしたとのお知らせ。

以下のページにアップロードされた画像のURLが変更となり、当該ページでのみ表示される仕様に変更となりました。メンテナンスのお知らせ 2006.11.08

以前に mixi の画像はどう配信されているのか という記事を書いたので、どのような認証方法にしているのか気になってちょっと見てみた。

画像の URL を見てみると、http://ic50.mixi.jp/p/(ランダムな文字列)/45532d00/diary/11/09/(ownerid)_123.jpg のようになっている。多分これは、日記の表示時に画像の URL をランダムな文字列をワンタイムで自動生成して画像を表示させ、一定時間(おそらく数分)後には標準の「画像を表示できません」と言うメッセージが表示されるようにしていると言う仕組みだろう。そしてどうやらこの自動生成された URL の画像自体は、一時的にとは言え認証無しに誰からでもアクセスできるようだ。画像のホスト名が ic50.mixi.jp のように mixi.jp ではないので、自明といえば自明だが。

まとめるとこんな具合に動いているのだと思われる。

1. 日記で画像を表示する。画像の One Time URL は表示時に DB から自動生成される
2. 画像の URL をどこかにコピペした場合、一定時間以内ならアクセス制限に関係無く mixi 外部の誰でも閲覧可能
3. 一定時間後に URL の有効期限が expire し、画像が「画像を表示できません」に置き換わる

数分で見られなくなるということで改善ではあるし、先日「対処できません」とお手上げしてからの対処期間を考えると現実的な方法ではあると思うが、「当該ページのみで表示される」と言うのはあまり正確な表現ではない。

1  mixi2gmail.rb が動かなくなっていた

どうも mixi.jp で login.pl の html が変わったらしく、email field に type=text の記述が無くなったようだ。それだけなら問題ないはずが、WWW::Mechanize では input に type 指定が無いと skip してしまう仕様だったらしく form fields を正しく拾えていなかった。とりあえず WWW::Mechanize::GlobalForm#parse の case 文に else で default behavior を突っ込んでおく。しかし WWW::Mechanize 自体があまりメンテナンスされていないようだし、Plagger に移行するなり他のツールを使うなり自分でメンテナンスするなりしたほうがよい感じ。どうしようかな。

1  ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解

mixi の画像が外から全て見えてしまうのはサービスポリシー的に不具合だろうとは思っていたが、IPAに脆弱性扱いされた上に「修正できません」と白旗をあげてしまったようだ。折角上場して資金も集めたんだから、せめて今後は頑張って頂きたいところ。
それはともあれ mixi の画像管理の仕組みに付いて、コメントしたのに併せて少しだけ調べてみた。現状の仕組みは結構シンプルのようだ。

去年 9月の資料 mixi 開発物語 にある構成がそのままだとすると、画像は全て mixi.jp の html 本体に使われている mod_proxy のプロキシサーバを経ずに直接配信されているらしい。過去に「Squid で DNS ラウンドロビンしている」と書かれている img.mixi.jp の部分は、現在は Webコンテンツの大規模分散配信サービス Akamai を使って配信されている。

img.mixi.jp CNAME img.mixi.jp.edgesuite.net
img.mixi.jp.edgesuite.net CNAME a899.g.akamai.net

img.mixi.jp は mixi の共通画像(UIのボタンや背景)やプロフィール写真、コミュニティ画像などの「表示頻度が高くて変更頻度が低いもの」に使われている。仕組や負荷的に、この部分を認証制御可能にするのはかなり難しいだろう。

一方で日記など、登録数は多いが登録後数日でアクセスが殆んど無くなるような画像は img*.mixi.jp や ic*.mixi.jp などの mixi が持っているサーバに割り当てられているため、制御出来る可能性がある。同資料によればこれは「イメージクラスタ」と呼ばれるもので、以下のような設計思想らしい。

• ストレージと配信を同じサーバで実施
• アップロードされた画像は複数のホストに分散配置
• 画像の場所は MySQL で管理
• 古い(参照がほぼ無い)写真は古い写真専用クラスタに移動

表示系としては、単に「頑張って画像をひたすらHTTP(S)で吐くウェブサーバ」以上のものでは無い。そんなわけで画像サーバが認証系の外にあるのは設計当初からの「仕様」なのだろう。

これをなんとかするならば、以前試みたように Cookie の範囲を .mixi.jp にした上で画像処理サーバ側でも認証状態の確認をするようにするか、前段の mixi.jp プロキシで認証状態を確認した上で画像サーバのコンテンツを返す形が思い付く。前者は以前に Cookie の仕様的に不具合が出るブラウザ (携帯電話の NetFront や w3m など) で失敗しているので、やるとしたら後者だろうか。後者も画像参照系の構造はかなり変える必要があるだろうし、画像配信をプロキシ越しにする負荷も高そうではある。

ちなみに以下のあたりが mixi が使っている IPアドレス。てきとうに whois しただけなので、もっとあるかもしれない。画像サーバをそのまま表に出している都合上、結構な数がある。

59.106.61.64 - 59.106.61.127
59.106.41.64 - 59.106.41.127
59.106.80.64 - 59.106.80.127

個人的には「インターネットに出したら SNS だろうが漏洩のリスクがあるのは一緒でしょ(意訳)」と言う mixi の主張は最もだと思うのだが、それって自分のサービスを否定している気もするので、まぁなんとかするように頑張るといいのではなかろか(他人事)。