関連: 開発談義, official:トラックバック
TrackBackとは†
- tb-standalone 日本語化 + メール送信
- ねこめしにっき: excerpt は 255 バイトでぶった切るのが慣例のよう
ツール†
- Wizbang Standalone Trackback Pinger
セキュリティ†
- これを引用するということは、PukiWiki の function sanitize($param) じゃ不十分というか懸念しているということなんですか? > 引用した方
- 引用した人間じゃありませんが、sanitize() だけでは不十分でしょう。ここの文脈(HTMLに吐き出す前)のサニタイズの意味は、「ちゃんと htmlspecialchars() してから出力してますか?」でしょうね。
懸案事項†
- 現在のarticle形式で過去の記事を別ページ送りにするような運用ではデッドリンクが発生する
- calendarでページを(hoge/yyyy-mm-ddで)作成している人だけではないだろうという懸念
- 対応にはarticleプラグインの代替となる仕組みが必要。--例えば一つの記事=1ページで管理してcalendar_viewerのように複数のページをincludeして1ページに見せるなど。
- 1つの html を生成するタイミングで、1つの TrackBack で管理すべきであると私も思うので(どこぞで議論されていたんですが)、それをどう表示しようが関係ないことになります。なので、PukiWiki ならページで1つ管理することになると思います。この考え方だと、この場合は、PukiWiki 固有にすることになりますから、やはり TrackBack は名乗れないことになります。それは、tDiary で指摘されたのと同じです。-- upk
- ページ送りの部分は、一度消すという運用(ページが消えたら、TrackBack Ping URL を管理しているデータも消す)をすればよいんですが、上書き更新だと、意図しないリンクになってしまいますねぇ。確かに。-- upk
- 現仕様が、そもそもとしてゴミが発生する。というものなので、article形式が云々じゃなくても懸案だと思います。-- upk
- なので、究極は、TrackBack Ping データを、手動で消すか?更新のタイミングか、どこかのタイミングで、リンク切れを識別し、消すか?などで逃げるしかないのかなぁ?と思います。いずれにしても、TrackBack を実装した後ででも、保守をどうするか?という仕組みを作れば、維持できると思うので逃げることは可能だと思います。まぁ、スマートじゃないんですけどね。-- upk
技術仕様(まとめ) by upk†
私になりに理解した内容を、つらつらと。
間違いなく、TrackBack技術仕様書(邦訳)の方が良いんでしょう。
- 何か PukiWiki 内のページでリンクした。
- そのリンクした URI は、ページ更新のタイミングで取得する。
- その URI を使って、ドキュメントを GET する。
- GET したドキュメントに埋め込まれた TrackBack Ping URL を取得する。
- その TrackBack Ping 用 URL を使って POST して情報を相手サイトに伝達する。
まぁ、こんな流れです。
TrackBack Ping URL の取得方法†
TrackBack Ping の送信†
上で得た TrackBack Ping URL から、POST メソッドで送信する。
POST http://www.foo.com/mt-tb.cgi/5
Content-Type: application/x-www-form-urlencoded
title=Foo+Bar&url=http://www.bar.com/&excerpt=My+Excerpt&blog_name=Foo
これでは、例えば、excerpt に書かれている文字が、UTF-8なのか? EUC-JP なのか?
などで、色々と議論されている。
- 「Webサイト間のピアツーピア通信/通知のためのフレームワーク」 の 日本語文字コードの問題 でまとめられている。
- PukiWiki に関して言えば、function sanitize($param) で $_POST を解析し、突入するようにすればよいのであって、プラグイン化すれば、それは自然にそうなることで、特段の問題でもないと考えている。ここで問題となるようであれば、sanitize() の実装をチューニングすればよいことである。
パラメータ†
- title
- url
- excerpt
概要を 255文字程度で。ダブルバイトな文字での 255 なんという長さでの切断は
難しいので、行読みして、というような段取りでしか PHP だとちょっと。最新版では、
mb シリーズも強化されてきたので、できそうではあるものの、PHP に依存するので、
そこまでは、とも思っています。
- blog_name
WebLogやblogについて LowLife.jp
で説明されている。
この blog_name という blog に拘る必要もなく、
処理システム名でも記述するのだろうと理解しています。
__mode=rss†
TrackBack に対応したとするならば、
本文中に、TrackBack Ping URL を埋め込んだ TrackBack Ping URL に、
__mode=rss というクエリーストリングを付加した URI で GET を受信した場合には、
そのドキュメントに対して、継続された議論への RSS 情報を出力するように、
実装しておく必要がある。
http://www.foo.com/mt-tb.cgi/5?__mode=rss
<?xml version="1.0" encoding="iso-8859-1"?>
<response>
<error>0</error>
<rss version="0.91"><channel>
<title>TrackBack Test</title>
<link>http://this.is/the/trackback/item/link/</link>
<description>Description of the TrackBack item</description>
<language>en-us</language>
<item>
<title>TrackBack Demo</title>
<link>http://this.is/the/permalink/</link>
<description>Excerpt</description>
</item>
</channel>
</rss></response>
- __mode=rssは、TrackBack技術仕様書ver1.2では機能が削除されている。
__mode=view†
TrackBack技術仕様書では
定義されていないものの、本家 で
利用されていたので、同じ挙動で実装している。単に、受信した TrackBack を
表示する機能であり、本文中に埋め込んだ TrackBack Ping URL に、
__mode=view というクエリーストリングを付加した GET を受信した場合に、
一覧表示される。
表示順: 受信日時の直近から降順としました。ホットな話題が先頭にくるように...
TrackBack ID†
TrackBack ID は、数字だぁ。と定義されているドキュメントも、
ないわけではないものの、明確には定義されていない。
PukiWiki のページ個々に、マッピング用 ID を
これがために採番するのもなぁ。FrontPage は1。とか。
なので、そんなマッピングは行っておりません。ページ名の長さに左右されることの
ない、常に一定な長さとなる方法にしちゃいました。この方法で、ページ名が重複する
ことがあるのなら、逆に、このハッシュは問題です。というところから、採用しちゃいましたけども。
ということで、PukiWiki ユーザでかつ、同じ文字コードで運用している
サイト間では、TrackBack ID を、計算することが可能です。
サイト個々でユニークとはなりません。しかし、それが仕様ではないので、
ページを GET することもなく、計算しちゃったり。ということはしておりませんし、
今後、保守を行う上でも、しちゃいけません。
コメント†
- showrssの全てのリンクへpingを打ってしまう問題点。BugTrack/461 よりコピー -- merlin
- $trackback=1のときに、#showrssで表示される全部のURLにPingを打つのはまずいんじゃない? --
- showrssで表示しても、そのページのタイムスタンプは変わらないし、trackbackがping打つのは文書更新時だったはず(実際の動作は未確認)なのでそれって起こらないんじゃない? -- merlin
- tb_sendは内部でページソースをconvert_html()して、できたHTMLソースから<a>タグのhref属性の値を抽出し、片っ端からPingを打とうとする仕掛けになっています。#showrssが出力するURLも対象になります。URLの指すページに<rdf:RDF>が埋め込まれていれば実際にPingを打ってしまいます。これは…まずいですね。 -- ぱんだ
- 場当たり的なパッチ(行頭#および表内の#をプラグインとみなさないように、空白を1個入れる XD) お試しください。 -- ぱんだ
diff -u -r1.13 trackback.php
--- trackback.php 3 Sep 2003 05:53:45 -0000 1.13
+++ trackback.php 11 Sep 2003 00:11:43 -0000
@@ -84,6 +84,7 @@
set_time_limit(0); // 処理実行時間制限(php.ini オプション max_execution_time )
+ $data = join("\n",preg_replace('/(^|\|)#/','$1 #',explode("\n",$data)));
$data = convert_html($data);
// convert_html() 変換結果の <a> タグから URL 抽出
- 仕様的から見れば、まずいものでも無いと思います。ダイナミックに生成された結果であっても、その時点でリンクしたのは事実なわけですから。ただ、PukiWiki として、スタティックな定義内容に対して、TrackBack を送信するものとして、各種プラグインなどにより、動的に生成した内容に関しては、取り扱わないこととする。と決めるかどうか?だと思いますが。この内容で、動的な値に関しては取り扱わないこととするのであれば、それは、たぶん、必ずTrackBack を送っても、どこにもリンクの痕跡が無いじゃないか?ということを心配しての内容なのだろうなぁ?と解釈しますが、そうなってくると、pcomment などでのコメントが増殖した際に、ページを分けたいんだけど。しかも自動で。なんてもんも同罪として扱うべき範囲になってくる思っています。なので、どういう場合は、どうするのが適切なのだろう?なんですけどねぇ。-- upk
- Trackback Ping を送って、価値のある期間が、RDFなどの更新間隔に左右され、一定ではない。ということなのでしょうけどね。は、理解した上で、じゃ。それが1年間隔なら、どうしますか?だけのことです。なので、PukiWiki としては、その一定の判断基準から、そうしたと決めてしまえば良いだけだと思います。やはり、価値が無くなる恐れがあるものでかつ、自動的に更新されるもの。というイメージなのでしょうかね? -- upk
- どうしたもんですかね。いたずらで#showrssを大量に書き込まれたりすると参照先に迷惑を掛ける可能性もありますが… -- ぱんだ
- それも確かに、相手サイトに迷惑をかけることになりますね。使い方を間違えば、DoS攻撃にも。やはり、各種プラグインにより動的に設定される内容を除いたもの。ということなのでしょうかね?で、対応は、プラグインと認識される # および &xxx{} など。ということでしょうか? -- upk
- 対応策として、convert する際に、オプションで、プラグイン展開をしない。という逃げと、オリジナル文書から、プラグインと認識される箇所を除く。のどちらがロジック的に簡単か?ということでしょうかね? -- upk
- あ。でも、そんなことを言い出すと、「じゃ、TrackBackサポートのPukiWikiにurlを大量に書き込めばDoS攻撃できちゃうじゃん」などと考える輩も出てくるかもしれないし…うーん。 -- ぱんだ
- トラックバック機能のリンクタグにonclick="OpenTrackback(this.href); return false"が抜けてるのでは? -- Logue
- 2ちゃんねるや、したらばからPingを送ってるはずなのに、TrackBackとして反映されません。 --
- GET methodによるtrackback pingの受信にも対応されました。 -- reimy
- ping送信荒らしができてしまうなど、かなり問題がありますけど、ping送信をここを参考に実装してみました。→http://logue.xrea.jp/?TrackBack -- Logue
関連ページ†