July 28, 2005
amazlet の文字化け
[ amazlet ]amazlet を今使うと、画面が文字化けしてしまうようです。
調べてみたところ Amazon Webサービス (ECS3) の応答メッセージ自体が文字化けしているようで、ちょっといかんともしがたい状況です。先方のシステム復旧待ちです。
15:32 追記: 直りました
July 08, 2005
naoyaのはてなダイアリーに移転
[ ウェブログに関すること ]僕のブログですが、naoyaのはてなダイアリーに移転しています。検索に引っかかるということもあるので、このブログはこのまま残しておきます。
いずれ、フィードのURLも301で向こうに飛ばすかもしれませんが、とりあえずはフィードは現状維持させておきます。
June 19, 2005
amazlet から在庫状況を削除
[ amazlet ]ECS 3 で在庫状況の表示 (Availability) に不具合が発生しているらしく (この辺)、在庫状況の表示がおかしかったので、amazlet から在庫状況情報を取り除きました。
June 03, 2005
ping の順番
[ XML ]FeedBurner をはさんだ場合、FeedBurner と本チャンの RSS を同期する必要があり、普通に巡回もしてくれるけど weblogUpdates.ping を http://ping.feedburner.com に飛ばすことでリフレッシュタイミングを早めることができる。
一方、はてなRSS は http://r.hatena.ne.jp/xmlrpc に ping することでクロール間隔を早めることができる。
この両者に ping を飛ばす場合、順番に気をつけないと、FeedBurner との同期が完了するまえに巡回君が来てしまう可能性があり、いや〜んなことになる、というのに気付きました。FeedBurner → はてなRSS の順番が正解。
ということでテスト中です。
フィード用 AdSense は map タグ
[ XML ]フィード用 AdSense は map タグを使ってるんですね。map をサニタイズ対象にしてないフィードクライアントってどれぐらいあるんだろうか。
FeedBurner
[ XML ]なんとなく、このblogのRSSをFeedBurnerで燃やしてみました。
あ、最近はnaoyaのはてなダイアリーの方をメインに更新していますので、こちらもよろしくお願いします。NDO::Weblogを今後どうするかは検討中。
May 14, 2005
Movable Type 脆弱性の発表は脆弱性ではない、のまとめ。
[ Movable Type ]「【重要】 第三者による不正アクセスを許す危険性の対策について」で発表された内容について、「Movable Type の脆弱性の件 : NDO::Weblog」のコメント欄あたりでごちゃごちゃ書いていたことをまとめておこう。
ということで、コメントでやりとりしていた話を ishinao さんがまとめています。とてもよくまとまっているので、御一読を。
あと、今回の件でMT に脆弱性が、という記事を書かれた方は、その後のフォローとしてこういった記事も一緒に引用あるいは参照として記載しておくと、周囲の人の理解が正しい方向へ向かうので有益ではないかと思います。
May 13, 2005
Movable Type の脆弱性の件
[ Movable Type ]Movable Type(ムーバブル・タイプ)の脆弱性により、第三者による不正なアクセスが可能であることが確認されました。Movable Typeのセッション管理で使われるCookieの値に、ハッシュ化されたユーザーアカウント情報が含まれており、以下の条件を全て満たした場合に、第三者による不正なアクセスが可能になります。
というアナウンスが出ていてるのですが、これに関してメディアとか巷の blog で過剰に反応しているものが散見されます。
が、アナウンスで赤字で強調し指摘れてるところを良く読んでからも分かるとおり、これは Movable Type そのものの脆弱性ではないですし、そもそも脆弱性なのかどうかも怪しいという話です。
第三者が、Cookieの値を取得する。
Cookie の値を取得されたら、Movable Type に限らず大概のどんなブログ、どんなツールでも不正アクセスが可能です。(AtomAPIとログインパスワードが..とありますが、実際には Cookie を抜かれたらその Cookie を仕込んで mt.cgi そのものにログインが可能です。)
近頃の一般的なウェブアプリケーションでは Cookie によるログインのセッション保持というのをやるので、Cookie の値そのものがパスワードと同等の役割を持っています。それゆえ、(アプリケーションの欠陥で)Cookie が漏れるような事態は脆弱性と言えるでしょうが、今回の件は Movable Type に Cookie 漏洩の脆弱性が見つかったわけではないです。
Cookie を抜かれないために http から https にするとか、それはもう Movable Type の問題ではなくそのシステムを個人としてどうするかという問題ですね。
技術について詳しくない個人の方はともかくとして、メディアの人はもう少し考察してから記事を書くなりなんなりした方がよいんじゃないでしょうか。
追記
mt.cfg を隠さないとやばい、見たいな話にもなっています。確かに人に見せるような代物ではないので見えないように対処を行っておいたほうが良いとは思いますが、これも見えたからといってじゃあそのサイトが何か問題を突かれて云々かというとそういうものではないです。
mt.cgi のパスが知れてしまうと問題、という認識は間違いです。mt.cgi は普通コメントとかトラックバックとかの cgi と同じパスに置かれているのだし、HTML や rsd.xml の中身を見ればそんなものはすぐにでも分かります。そこにアクセスされたら危険というものはアクセスされないように任意の名前で隠せばセキュアという認識が間違っています。(この辺の語りは高木さんの役割かもｗ)
mt.cfg の中には、ログインに必要なパスワードであるとか、DB に接続するためのパスワード、それから Cookie の値を何らかの方法で知るための値が記述されているわけではないので、見られたからってサイトが不正アクセスの被害を被るわけではないのです。
見られたら危険、というものだったらそれを、一般のアクセスからは物理的に見れない場所におく、例えばウェブサーバがハンドリングしていないディレクトリに置くとか、それが適切な対処ですが、mt.cfg はパッケージの中ではウェブに公開される可能性のある領域にもともと置かれています。開発者側の判断は、特に mt.cfg が見られたからといって脆弱性が発生するわけではないという認識の元でしょう。見られたら気持ち悪いファイルではあるので、隠しておくに越したことはない、程度のものです。
この話に関しても Six Apart Japan の文書が誤解を招きやすい表現になっているという点は否めないですけれども。
May 09, 2005
blogWatcher 2.0 / なんでもRSS
[ インターネット ]当初のご案内より少し遅くなってしまいましたが, 本日第2版を公開いたしました. 御利用下さり, これまで同様ご意見を頂ければ幸いです.
東工大の奥村研究室の研究成果である blogWatcher、その 2.0 が公開されています。なんというか、内部的に GETA から Lucene に変更されたなどの点もあるものの、外側のインタフェースが改良されていて、2.0 というより別物に近い印象。実用性を考えていろいろ変更したというのがよくわかります。
API があったり (OKUMURANK!) いろいろ面白いのですが、僕個人として一番これはいいと思ったのは、メインの blogWatcher ではなく blogWatcher の研究成果を利用して作られたなんでもRSSの方ですね。
名前のとおり(日付情報のあるサイトを)なんでもRSSに変換しちゃいますという代物で、ためしに僕が手HTMLで作っていたゲームサイト（オタい)のURLを突っ込んでみました。
その結果がこれ。正直かなりびっくりしました。HTMLをコピペしながら作ったものなので、規則性が若干崩れてるところがあったりするのに、その辺はちゃんと補正してかなり正確に記事を分割してRSSを生成しています。こりゃすげーや。
以前に東工大でblogWatcherのプレゼンを聴かせてもらったときに、その内部で利用しているコンテンツ・フィルタ (ページの日付情報やHTMLの規則性から、そのページがブログかどうかを判定し、かつデータ記事単位に分割するフィルタ) の仕組みを見せてもらって、これでなんでもRSSとか作れそうですねみたいなことをみんなでワイワイ言ってたんですけど、その成果物ですね、素晴らしいです。
早速色々使わせてもらいます。
May 05, 2005
Bookmarklet をサーバーサイドでメンテナンス
[ インターネット ]Bookmarklet を配布するときの悩みの種が、一度配布したコードのメンテナンス。ウェブアプリケーションの一機能として Bookmarklet を使う場合にこの問題は結構厄介です。
例えば、はてなブックマークは自分のブックマークにブックマークを追加するのに Bookmarklet を使うのですが、何か Bookmarklet の JavaScrpipt のコード側にバグがあったとか、機能を追加したいという場合に毎回アナウンスして Bookmarklet をセットアップし直してもらう必要があります。(今のところ、そういったことはないのですが。) ウェブアプリケーション、というかサーバーサイドアプリケーションの最大のメリットである、徐々に機能を追加していくというフローに、配布型の Bookmarklet の仕組みが合わないんですね。
それが悩ましいので、はてなブックマークの Bookmarklet は、それを実行した先でサーバーサイドのプログラムを呼び出して、そちら側になるべく機能を集中させるようにしています。
が、今日素晴らしい情報を発見。
bookmarkletを作るとき、IEでは500文字ちょい、Firefoxでは2000文字ぐらい(?)の文字数制限がある。また、作った後に一行にまとめたり、デバッグしたりも大変面倒。でもそれがとても簡単な方法でどうにでもなることをインターフェイス！インターフェイス！の人に教わった。
表題は文字数制限をなくす、ということなのですが、実際のコードは document.createElement で script エレメントを作ってやってそこで src で外部ファイルを読むようにしてやるというもの。
この方法を使えば、JavaScript のコードそのものをサーバー側に置いた Bookmarklet が作れます。素晴らしい。
より過去の記事をよみたい方は過去ログ一覧ページもどうぞ。
author: kmorita
date: 2005.12.29