駄目。やっぱ、TrackBackは実装しない。
勢い込んでDAO作って、tb_addなるモジュールをコピペして中身を書いていた途中。
簡易spam判定でURLをGETしたコンテンツから検索する所を書き始めた瞬間。
「・・・あれ？YakiBikiのURLって、URLクエリ使ってるから、パラメータの順番変わった瞬間に判別不能にならね？」
YakiBikiのデフォルトのURL生成関数は、mod_rewriteを使えない環境向けに単純にURLクエリとしてパラメータを繋げていきます。
さらに「デフォルトモジュール」を設定する事で、
http://your.yb.site/
というURLで検索画面を表示させたりすることも出来ます。（普通はトップページでWikiページ表示）
これが簡易spam判定にどう影響するかというと、トラックバック元のエントリから
http://your.yb.site/?mdl=view&id=1234 http://your.yb.site/?id=1234&mdl=view http://your.yb.site/index.php?mdl=view&id=1234 http://your.yb.site/index.php?id=1234&mdl=view
の四種類の内いずれかが入っている事、という判定になります。更にデフォルトモジュールがviewに設定されていた場合は
http://your.yb.site/?id=1234 http://your.yb.site/index.php?id=1234
も検出対象に含まれます。一方デフォルトモジュールがviewに設定されていない場合は、逆にこの二つは検出対象から除外しなければなりません。
さらにURL生成部分はHOOKにしてユーザーカスタマイズが可能になっています。これでmod_rewrite対応のURLになるように弄られていたらとなると、ややこしくてなりません。
例えばサービスとして提供する形態で、msakamoto-sfが思う様にサーバーのmod_rewrite等で「綺麗な」URLに統一できていたのであれば、こうしたURLのぶれなど考える必要はなくなります。mbstringも使えますし、Services_Trackbackを使う事だって出来ます。
あるいは上のようなURLクエリではなくて、一般的なWikiのURLのように
http://your.wiki.site/?(ページ名のURLエンコード) http://your.wiki.site/index.php?(ページ名のURLエンコード)
で統一されていれば簡易SPAM判定も可能だったかも知れません。しかし、YakiBikiでID指定を採用したそもそもの理由が日本語をページ名に使用した時のやたら長くなるURLを回避する為です。YakiBikiは"/"による仮想ディレクトリの使用を強く想定している為、長いページ名を前提としています。そうなると、ページ名エンコードの上の一般的なWikiのURLにしてしまうとURLが非常に長くなってしまい、メールなどに貼り付けた時に折り返されてしまいます。そうした煩わしさや見づらさを回避する為のID指定でした。またmod_rewriteを使わない理由は、Apache以外のWebサーバ、例えばIISなどでも安心して動かせるようにする為です*1。mbstringなどの拡張を前提から外しているのも、海外のレンタルサーバ上で動作させた時にそれらの拡張がインストールされているとは限らないからです。
YakiBikiはコンテンツの操作をかなり制限する方向のソフトですので、認証が挟まらないTrackback-Pingとはもともと相性が悪いのかも知れません。
というわけで、リビジョン398で一度はDAOでTrackbackを実装しましたが、それも消してしまいます。当面はYakiBikiはTrackbackの送受信とも実装しない事とします。
受信が駄目でも送信なら・・・とも思いましたが、でも「こちらからTBはいくらでも打てるけど、打たれた側からのTBは受け付けない」というのって何だか印象悪いなと。
YakiBikiって元々コンテンツを認証で外から隠すためのツールなので、双方向のコミニュケーションを目指すTBみたいな技術とは相容れない部分があるというのが今回の実感でした。
