nDiki : cookie

WiKicker 認証 キャッシュ WikiPage Apache パケ・ホーダイ Basic 認証 FOMA Web ブラウザ HTML DiKicker Memcached Mozilla nDiki URL proxy メモ モバイル Gmail パスワード データベース Galeon Debian MovaTwitter htpasswd プロトコル D703i NTTドコモ CGI プログラム CGI 携帯電話

■ [ Debian ] Galeon と cookie 期限

なぜか手元の Galeon が hns / wiki の cookie をそのセッション限りでしか保存してくれなくなった。

Mozilla or Firebird への乗り換えを検討。

• [ Debian ] 昨日の cookie 問題は Privoxy のフィ... (2003-12-22)
• [ Debian ] Mozilla 系全滅 (2003-10-21)
• [ Debian ] 12:30 Galeon 0.12.1-1 (2001-09-18)
• Galeon から Mozilla へ移行 (2004-07-11)
• [ Debian ] 18:30 続 wmGrabImage (2002-01-20)

■ [ Debian ] 昨日の cookie 問題は Privoxy のフィルタのせい

昨日の「Galeonがセッションを越えてcookieを保存しなくなった」問題であるが、Mozilla も同様。 で、Mozilla の Live HTTP Headers でチェックしてみると Set-Cookie: の expires がばっさり捨てられている。アレ?

で確認したら Privoxy がフィルタリングして削除していたらしい。 この間まで問題なかったのに、なんでだろ。 まいっか。

@ やっぱりGaleon

これを機会に Mozilla or Firebird に乗り換えようかと思ったが、やはりどうもしっくりこない。 Galeon の「任意のブックマークフォルダをツールバーにできて、かつ左側*1に表示できる」という機能が便利なのだが、これが他ではサポートしていないんだよね。

Mozilla の「サイドバー中のブックマーク」ではフォルダをクリックするとトグルで展開するだけなの対して、Galeon のはパーソナルツールバーのそれのようにそのままフォルダがメニューとしてポップアップしてくれる。 この機能が捨てがたい。 それから、ポップアップしたブックマークメニューですぐそこに追加できるというのも特長。 Mozilla でもこれらができれば、移行してみたいのだが。

• [ Debian ] Galeon と cookie 期限 (2003-12-21)
• Firefox ユーザプロファイル作り直し (2005-09-11)
• [ Debian ] 12:30 Galeon 0.12.1-1 (2001-09-18)
• [ Debian ] Galeon 1.3.12 (2004-02-03)
• [ Debian ] Mozilla 系全滅 (2003-10-21)

■ [ WiKicker ] 自作自演

けいむなさんの

「若い方達の文章はとても似ていると思うのですが同一人物ということはないですよねw」

という警鐘が気になって、過去の書き込みのログをチェック。

同一PC(cookie)から、異なるユーザ名での書き込みというのがある程度確認できだのだが、

• ユーザ名の表記ゆれ
• 毎回違う名前にしているが、悪質ではないもの(匿名的な書き込み)
• PCの共有(?)

というのは問題ではないと判断。 しかし1件だけ、ちょっと悪質な自作自演あり。 通常?のユーザ名と別ユーザ名を使い分け、また某アイドル名を騙ってコメント書き込んだ後にその内容に対して自身でコメントを書き込むなどをしており実際に他のユーザに誤解を与えていた。

確認できる範囲でそのユーザの書き込みを削除。 不毛な作業で疲れた。

• WiKicker でドメイン名なしの URL でセッションがはれなかった理由 (2006-11-10)
• WiKicker 0.41 リリース - cookie まわりの処理を変更 (2006-12-03)
• [ WiKicker ] Last-Modified: 実装準備 (2003-09-17)
• [ WiKicker ] キャッシュまわりにバグ (2004-06-05)
• Wikiの文法の標準化 (2004-02-10)

■ [ WiKicker ] WikiPage のHTMLレンダリング結果のキャッシュ

ようやく、HTMLレンダリング結果のキャッシュに着手。 cookie ベースでユーザ毎のカスタマイズ(名前やTZ)があるので、デフォルトのまま表示リクエストのみキャッシュが効くようにする。 キャッシュによる高速化を受けるのでは投稿してくれている常連ではなく検索エンジンから飛んできた一見さんということになるが、サーバの負荷が下がれば間接的に常連さんへのレスポンスも良くなるかと。

変換されたHTMLフラグメントをMemcachedにキャッシュ。 最初、キャッシュを有効にすると逆に遅くなってしまって「まいったな」と思ったが、リクエスト処理終了毎にdisconnect_all するようにしたら、キャッシュの効果を体感できるぐらいの速度が出るようになった。

• [ WiKicker ] キャッシュまわりにバグ (2004-06-05)
• [ WiKicker ] Last-Modified: 実装準備 (2003-09-17)
• DiKicker に grep 検索機能を追加 (2007-02-02)
• [ WiKicker ] Memcached を使った検索結果のキャッシング (2004-01-15)
• [ WiKicker ] Memcachedのメモリ使用量 (2004-02-15)

■ [ WiKicker ] キャッシュまわりにバグ

Memcached まわりをいじったので、キャッシュ具合をテストしていたら変な現象が。 WikiPage が表示されるべきところに、検索結果が表示されている。 あれ?

@ ページの内容が表示されるところに検索結果が

WiKicker では WikiPage のレンダリング結果も検索結果もキャッシュしているが、それぞれ別のキャッシュキーになるようにしている (WiKickerのバージョンを $V とすると、'$V:h:ページ名' と '$V:s:検索語')ので混ざるはずがないんだけれどな。 キャッシュしているデータの形式も違うし。

最初は Memcached まわりのアップデートで不具合がでたのかと思ったが、戻しても変わらない。ということは、ずっと以前からこの問題が発生していたのか。 やば。 設定でニックネームを設定している(cookie に保存している)と、その Web ブラウザに対してはキャッシュ機能が働かないようになっているので発見が遅れてしまった。

で結局コードをチェックしてみたら「WikiPage 表示と検索結果表示の View クラスを同じにしていたため、検索結果のレンダリングが WikiPage レンダリング結果と同じ領域にキャッシュされる」という風になってしまっていた。 ということで誰かがページ名で検索するとそれがキャッシュされてしまい、ページを読もうとしてもキャッシュ破棄されるまで検索結果が表示されてしまうというひどい状況になっていたと。

修正。

@ キャッシュキーのバグ

Memcached の出力をチェックしていたら、たまにエラーが起きていることを確認。 Memcached のプロトコルをチェックしたら、キーには制御文字と空白は使えないとある。 Cache::Memcached を見たらキーはそのまま through するだけ。 ということでページ名に空白が含まれている場合などの時には、まずい事になっていたようだ。 こちらは、キーを自前でエンコーディング(ページデータベースファイル名の作成に使っている base64 の亜種)するように修正。

• [ WiKicker ] SpeedyCGI 対応するも…… (2003-11-09)
• [ WiKicker ] WikiPage のHTMLレンダリング結果のキ... (2004-02-14)
• [ WiKicker ] Memcached を使った検索結果のキャッシング (2004-01-15)
• [ Perl ] Memcached を使ってみる (2004-01-12)
• [ WiKicker ] Storable 永続化データの互換性 (2005-06-06)

■ Spybot - Search & Destroy 1.3

会社の Windows BOX が重くなってきた感じ。 初めて Spybot を使ってみた。

検出されたのは cookie 系がほとんどのようだったので、spyware が直接の原因ではないのかもしれない。

• Win32 で WiKicker が落ちるのは binmode の設定忘れのせい (2005-04-18)
• 会社で Synergy (2002-11-15)
• CUPS で Debian から EPSON カラーレーザプリンタへ印刷 ... (2006-01-04)
• 去年の今ごろ (2002-11-15)
• ルータ直結有線生活 (2004-11-25)

■ DiKicker にそろそろコメント機能を実装するか

@ くっつき BBS

nDiki では、たつを氏が公開しているくっつき BBSを利用してコメント機能をつけている。 くっつき BBSは自前でBBS機能を実装しなくても、JavaScript Include を使うことでコメントをページに貼りつけられるという優れもの。

@ CGI プログラム経由の JavaScript Include 方式は遅い/負荷がかかる

nDiki では JavaScript Include する際、コメントがない(=JavaScriptファイルがない)場合でも404にならないようにCGI プログラム経由で貼りつけていた。 しかし、この方法だと1ページに多くのコメント領域があると何度もCGI プログラムが実行されるのでサーバへ負荷がかかる。

また Web ブラウザもHTMLの途中でscript要素が出てくると、そのスクリプトファイルを読み込んで処理するまで残りをレンダリングできない。 このためサーバが重かったりして、途中スクリプトファイルの読み込みでひっかかるとユーザ側でのページ表示完了が遅くなってしまう。

ということでこの方式をやめて、単純にコメントJavaScriptファイルのURIを指定するようにした。 その使わなくなったCGI プログラムで、tDiaryテーマ用の「commentshortクラスdiv要素」を書き出していたので、この部分は DiKicker に戻す。 現在のコードでは、コメントが無くてもこのdiv要素が出力されてしまうので、ちょっとみぐるしいがしばらくご容赦。

@ やはりDiKickerでネイティブにコメント機能を実装しよう

コメント内の AutomaticLink 処理や cookie の連動など、前からやりたいとは思っていたのでこれを機会に実装するかな。 いろいろ決めないといかん。

• 速度改善のため nDiki からくっつき BBS を外す (2005-10-16)
• [ DiKicker ] くっつき BBSをくっつけてみた。 (2004-05-04)
• nDiki に「はてなスター」をつけてみた (2007-07-11)
• iCalendar 形式経由でスケジュールを社内 Blog に表示 (2007-01-08)
• nDiki のコメント欄にコメントスパム (2005-09-12)

■ WiKicker でドメイン名なしの URL でセッションがはれなかった理由

 http://example/wiki

のように、ホスト部がドメイン名を含まないホスト名のみの URL でアクセスした場合、WiKicker では cookie ベースのセッション管理がうまく動かなかった。

cookie の仕様では、cookie の domain 属性で指定できる文字列はピリオドをいくつか含まなければならないことになっている。

しかし、ホスト名だけでアクセスしたサーバへは Web ブラウザは cookie を送らないというのは誤解。 domain 属性が省略されている cookie の場合は (アクセスするサーバの名前に含まれているピリオドの数が条件を満たしていなくても)ちゃんと cookie を発行したサーバへリクエストと一緒に送ってくれる。

WiKicker で何で駄目か確認したら、configuration オブジェクトの「cookie の domain 属性を決めるメソッド」で、「cookie.domain というプロパティ設定があればそれを」、「無ければ HTTP_HOST 環境変数の値を」 domain 属性で使う値として返すようになっていたから(って書いたのは昔の自分)。

次回のリリースで修正。

• WiKicker における PageName 最長文字数 (2006-06-10)
• [ WiKicker ] キャッシュまわりにバグ (2004-06-05)
• ケータイ用にプライベート Wiki を設置 (2008-01-07)
• FoxyProxy と autossh で社内 Web ページを閲覧 (2006-06-03)
• ノート PC で Apache Virtual Host (2004-12-15)

■ WiKicker 0.41 リリース - cookie まわりの処理を変更

11月1日以来、約1カ月ぶりのリリース。

ドメイン名なしの URL でセッションがはれない問題を修正。

DiKicker の方は、「n 年日記機能」、「diary-article:」の追加など。

• mixiに登録 (2004-11-19)
• [ WiKicker ] 日記機能開発開始 (2003-12-27)
• mixi 用として DiKicker に RSS生成機能を追加 (2004-11-21)
• DiKicker (2003-12-28)
• 私的10大ニュース2004 [ web ] (2004-12-31)

■ ケータイ用にプライベート Wiki を設置

パケ・ホーダイを契約してから、MovaTwitter・RTM・モバイル Gmail などで携帯電話を活用するようになった。そんななか、決定打がないのが、ノートアプリケーション。電車の中などの隙間時間に、この nDiki の 下書きなどはケータイでできるようにしたい。

Google ドキュメントが使えればいいが、前年ながらまだiモードでは使えない。 メールベースでやる手もあるが、メモには良いものの再編集を繰り返したいようなものに難がある。

ということで自前でプライベート Wiki を立てそこに書き込んでみることにした。

@ iモードから WiKicker

使う WikiEngine はいつも通り自作の WiKicker。

書き込んだテキスト内のキーワードを nDiki へ自動リンクさせることができるので、パーソナルナレッジベースとして自分にとっては一番便利。書式も同じなので、Wiki に書いた下書きを、そのまま nDiki で使える。

肝心のケータイからの書き込みだが Ajax 等凝った技術を使っていないおかげで、問題なく FOMA 端末(D703i)からiモードで読み書きできた。WiKicker は UTF-8 でページを出力しているが、網側か端末側の処理かは知らないが今のところ問題なし。

なお認証は簡単に Basic 認証で済ますことにした。 安全とは言えないがそれほど重要なデータを置くわけではないしいいかな。 cookie は必要ないし WikiEngine に手を入れなくてもよいので、すぐできるのはコレ。

ユーザ名とパスワード付きのトップページ URL を端末でブックマークしておけば1発でアクセスできる。

@ Google Mobile Proxy 経由で使う

これでケータイ(と PC)から使えるプライベート Wiki を設置できたわけだが、なにぶんもともとケータイをサポートしている WikiEngine ではないため、長いページの分割機能などはないのがちょっと不安。PageName で生成される URL が長くなった時の振る舞いもちょっと不安。

そこで Google Mobile Proxy (http://www.google.co.jp/gwt/n) 経由で Wiki を使うことにした。 ページを携帯端末向けに変換してくれる proxy で、Basic 認証もできるしフォーム の POST もできる。

Google Mobile Proxy 経由で見たページ内のリンク先も全て自動的に proxy 経由になるので、 PC 向け Web ページの URL を書いておけばそのまま携帯電話で見ることができる。

安全のためか、比較的短い一定時間立つと認証の再確認画面が表示されてしまうが、ユーザ名とパスワードを入力すれば、セッションは継続される。 テキスト編集に時間がかかってしまうと POST する時にひっかかってしまい認証の再入力がちょっと面倒だが、再認証が通れば POST リクエスト自体は有効で書き込みがロストすることはないようだ。

しばらくはこれで読み書きしてみよう。

• 半分は Twitter のためにパケ・ホーダイを契約 (2007-08-01)
• ビジネス用電話番号をマルチナンバーで追加した (2007-09-20)
• メールボックスを Gmail に集約 (2007-08-08)
• さよなら PHS (2007-02-10)
• SO905iCS ファーストインプレッション (2008-02-16)