そういえば、最近すごいんですよ>トラックバックスパム
大量生産型トラックバックスパムみたいです。
一時間おきに自動的に削除しているからいいんですけれど。
でも一時間は放置されるわけで、
POST時にエラーになるわけではないので、
もしかしたら....わたし....
.........なめられてるんでしょか??(^^;;;
トラックバックスパム削除cron。
削除条件をひとつひとつ登録していたので最近おいついていかなくなりました。
もう....アッタマ来て(笑)、奥の手?
「日本語がひとつも含まれていなかったらダメよ。」
ということにしました。
#これでいいのか??
削除処理の実行制御は変えていません。
mt_tbpingから、対象となるトラックバックを削除するsqlを1時間に1回、実行します。参照
今回は、sqlの中身をガラリと変えました。
トラックバックのタイトルと抜粋部分に日本語がひとつも含まれない場合に削除します。
delete from mt_tbping
where octet_length(tbping_title) = length(tbping_title)
and octet_length(tbping_excerpt) = length(tbping_excerpt);
日本語(2バイト文字)が含まれていないと、まともなトラックバックでも削除してしまうので、
それがちょっとなんですが....
今までのところ、英語だけの普通のトラックバックってなかったんです。
これでもう新しいスパムが来るたびに登録追加しなくてもすみます...あぁ楽ちん
2006.04.13
上記の対応をしたはずなのに、今日は10件のトラックバックスパムが削除されずに残っていました。
調べてみると、抜粋部分がnull。(敵も考えた?笑)
nullを含んだ比較はfalseとなるので、対象外となります。
っというワケであわてて下記のように修正。
delete from mt_tbping
where 1=1
and octet_length(tbping_title) = length(tbping_title)
and coalesce(octet_length(tbping_excerpt),'0')
= coalesce(length(tbping_excerpt),'0');
#いくらなんでも、トラックバックタイトルはnullにしませんよね?
サーバー機を購入したのが、今年はじめのような気がしましたが...
その後いろいろあって放置(爆
この年末年始はいつもよりお休みが長いので
できたらセットアップしたいなぁ~....
と思っています。
#あくまで希望
その前に、
1.最近、MTのカテゴリーがごちゃごちゃになっているのと
2.『自分の携帯からコメントできないコメントスパム対策』←auのPCサイトビュアーですが、IPアドレスがリクエスト毎に変わるんです
をなんとかしたくて、とりあえずMTだけでもアップグレードしよっか....
と思いました。
簡単に出来るつもりでいたんですけれどね。
サーバ上で解凍するだけかと....そしたら、perlがエラーを出してしまいました。
FC1ではperl-DBD-Pg Ver1.22
これでは古くてエラーが出てしまって駄目なんです。
....やっぱりFCのアップグレードが先ですね(^^;;;;
あまりにトラックバックスパムが多くって。
とりあえずの対応策。
mt_tbpingテーブルから"casino"や"poker"といったキーワードが含まれるトラックバックを削除するコマンドをcronで実行することにしました。
安易なやりかたですが、まぁ仕方ないです。
そのうち根本から考え直します....
#なんて言いつついつも放置してるじゃない?(^^;>自分
スミマセン
(1)用意しておくsql(/home/hogehoge/tbdelete.sqlという名前のファイルにしました)
delete from mt_tbping
where tbping_title like '%casino%'or tbping_title like '%poker%';
(2)crontabを編集(psqlを実行するユーザで下記コマンドを実行)
$crontab -e
(3)crontabの内容
SHELL=/bin/sh
MAILTO=kiyo
01 * * * * /usr/local/pgsql/bin/psql blog </home/hogehoge/tbdelete.sql
こうしておくと、実行結果がMAILTOで指定したユーザ宛てにメールとして届きます*^^*
とりあえずは1時間に1回の実行の設定。
しばらくこれで様子を見てみます。
頻度が低いようなら実行回数を減らす予定です。
タイトルの通り、最近なんだかすごく多くって....
#やっぱし、MTグレードアップするべきか。
今日はトラックバックスパム削除中にMovableType管理画面が異常終了してしまい
なんとも復活しなくなってしまいました。
頭にきたので、直接DBから削除したら無事復活。
そこでメモ。
トラックバックスパムを直接データベースから削除するコマンド。
(pokerやcasinoというキーワードが含まれていたら削除しちゃいます。)
delete from mt_tbping
where tbping_title like '%casino%'or tbping_title like '%poker%';
↓テーブルの中身についてのメモ(ここみながらdeleteしました)
http://blog.kiyo.com/archives/2004/10/trackback.html
最近、MovableTypeからトラックバック通知メールが届いて....
中身をみたら、スパムっぽくて、泡くって削除しようと思ったら、
「blogにはトラバされた内容が反映されていなかった...」
ということがちょくちょくありました。
その場合のトラックバックの内容は同じで、
あと、狙われるトラックバックURLもだいたい決まったものです。
『禁止IPに登録していたIPからのトラバなのかなぁ....?』
なぁんて、漠然と考えていたのですが、
ちょっぴり気合いを入れて(笑)確認してみたところ、禁止IPからではなかったのです。
じゃ、なにが悪いのだろう?
「メール自体がスパムなのかしら?」
とも考えてみたけれど、ヘッダを確認するとMailは確かにローカルのMovableTypeから送られてきています。
なにか法則があるのかな?
っと思って、同じトラバ内容を自分で送信してみました。
送信先は、ひとつ前のエントリー(今月はエラかった)です。
すぐにメールが届きました。
(メールの内容は以下のとおり。IPアドレスはちょっとアレンジしてあります*^^*)
そして、、、、やっぱり実際にトラックバックされることはなかったです。
Received: from hoge.kiyo.com (localhost.localdomain [127.0.0.1])
by hoge.kiyo.com (8.12.10/8.12.10) with ESMTP id j6LF6FMb017448
for <hogehoge@kiyo.com>; Fri, 22 Jul 2005 00:06:15 +0900
Received: (from apache@localhost)
by hoge.kiyo.com (8.12.10/8.12.10/Submit) id j6LF6FFb017446;
Fri, 22 Jul 2005 00:06:15 +0900
Date: Fri, 22 Jul 2005 00:06:15 +0900
Message-Id: <200507211506.j6LF6FFb017446@hoge.kiyo.com>
Subject: [megu's blog] エントリー 308 (今月はエラかった!) への新しいトラックバック
Content-Type: text/plain; charset="iso-2022-jp"
To: hogehoge@kiyo.com
Content-Transfer-Encoding: 7bit
From: hogehoge@kiyo.com
X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_60_70,HTML_MESSAGE,
NO_REAL_NAME,PLING_QUERY autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on hoge.kiyo.com
Status:
新しいトラックバックがあなたのウェブログのエントリー 308 (今月はエラかっ
た!) にありました
IPアドレス 123.123.123.123
URL: <http://www.astroyee.info/>
タイトル: theweb
ウェブログ: <a href="http://ancestor.astroyee.info/">ancestor</a>
<a href="http://antique.astroyee.info/">antique</a> <a href="http:
//bible.astroyee.info/">bible</a> <a href="http://candy.astroyee.i
nfo/">candy</a> <a href="http://cat.astroyee.info/">cat</a> <a href
="http://cheater.astroyee.info/">cheater</a> <a href="http://christ
ian.astroyee.info/">christian</a> <a href="http://dancing.astroyee.
info/">dancing</a> <a href="http://debt.astroyee.info/">debt</a> <a
href="http://fashion.astroyee.info/">fashion</a> <a href="http://f
igurine.astroyee.info/">figurine</a> <a href="http://fishing.astroy
ee.info/">fishing</a> <a href="http://horse.astroyee.info/">horse</
a> <a href="http://job.astroyee.info/">job</a> <a href="http://mail
orderbride.astroyee.info/">mailorderbride</a> <a href="http://mortg
age.astroyee.info/">mortgage</a> <a href="http://movie.astroyee.inf
o/">movie</a> <a href="http://paintball.astroyee.info/">paintball</
a> <a href="http://painting.astroyee.info/">painting</a> <a href="h
ttp://parrot.astroyee.info/">parrot</a> <a href="http://pharmacy.as
troyee.info/">pharmacy</a> <a href="http://photography.astroyee.inf
o/">photography</a> <a href="http://prayer.astroyee.info/">prayer</
a> <a href="http://relationship.astroyee.info/">relationship</a> <a
href="http://ring.astroyee.info/">ring</a> <a href="http://romance
.astroyee.info/">romance</a> <a href="http://romanian.astroyee.info
/">romanian</a> <a href="http://trading.astroyee.info/">trading</a>
<a href="http://webdesign.astroyee.info/">webdesign</a> <a href="h
ttp://wedding.astroyee.info/">wedding</a>
概要
astroyee
--
Powered by Movable Type
Version 3.01D-ja
http://www.movabletype.jp/
ためしに楽天のサイトに同じ内容のトラックバックを送ってみたら....
見事にトラバできてしまいました。
MovableTypeは何を見ているのかな?
何をもって、この内容のトラバを×としたのだろう?
#やたらに長いブログ名??
でもなんで、中途半端に通知メールだけ送ってきたのだろう?
.....って、結局「?」だらけです(^^;;;;;
#とりあえず、メモということで....
なにかわかりましたら、またエントリーします。
その前にバージョンアップですね。
バージョンアップした上で、同じトラバ内容を送ってみる。
それでどうなるか?ちょっと興味があります。
私のへぼへぼなコメントスパム対策も少しは役に立つことがあるようです。
最近になって、また何度かひっかかっているヤツがいることに気付きました。
コメントスパムのログ
以前に『コメントスパムを防御できた』というエントリーに対して「ソースを教えてください」とリクエストをいただいていたのに、なかなか実現できなくてすみませんでした。
やっとやっと....(いいのかどうかわかりませんが)、例として紹介させていただくことにしました。
断っておきますけれど...(笑)
決してベストな方法ではないと思います。
なにかの参考にでもなれば幸いです。
チェックの流れはコメントスパム対策とりあえずバージョン実装を参照してくださいね♪
◆チェックするための準備作業◆
(1)comments_check.plを作成する。
comments_check.plの内容
・REMOTE_ADDR情報を含み、かつユニークな値を持つ(例では時刻)文字列を生成する。
・生成した文字列を標準出力へ出力する(query_stringとしてセットされる)。
・生成した文字列をチェック用ファイル(check_file)へ出力する。
comments_check.pl
ソース例
#!/usr/bin/perl
$check_file = "/hogehoge/check_file";
open(LOG,">>$check_file");
$date = `date +"%H%M%S_%d%m%y"`;
chop ($date);
$addr = $ENV{'REMOTE_ADDR'};
$host = gethostbyaddr(pack("C4",split(/\./,$addr)),2);
print "damedamespam\_$date\_$host\_$addr";
print LOG "damedamespam\_$date\_$host\_$addr\n";
close(LOG);
※comments_check.plはSSIとして動きます。
※当プログラムがどこのディレクトリから起動されるか不定ですので、check_fileは固定パス(ルートからのフルパス)です。
※check_fileはどこに置いてもかまいませんが、SSIから読み書きできる権限が必要です。
(2)配置
comments_check.plをSSIとして呼び出し可能な場所に配置します。
例 /home/hoge/public_html/ssi/comments_check.pl
(3)権限の設定
例 $ chmod 755 /home/hoge/public_html/ssi/comments_check.pl
(4)lib/MT/Template/Context.pmの変更
MovableTypeのコメント呼び出し部分のテンプレートが
lib/MT/Template/Context.pm
にありますので、comments_check.pl呼び出し処理を埋め込みます。
例
(1160行目付近と1220行目付近の2箇所...MTのバージョンによって異なりますので、formタグを目標に探してください。)
<form method="post" action="$path$comment_script?<!--\#exec cmd=\"/home/hoge/public_html/ssi/comments_check.pl\"-->" name="comments_form" onsubmit="if (this.bakecookie[0].checked) rememberMe(this)">
(5)MTの管理画面から、テンプレート「Individual Entry Archive」の変更
formタグを見つけてください。
<$MTCommentScript$>の後ろに、comments_check.pl呼び出し処理を埋め込みます。
例
<form method="post" action="<$MTCGIPath$><$MTCommentScript$>?<!--#exec cmd="/home/hoge/public_html/ssi/comments_check.pl"-->" name="comments_form" onsubmit="if (this.bakecookie[0].checked) rememberMe(this)">
◆コメントが投稿された時のチェック◆
(1)mt-comments.cgiの修正
チェック用の関数(check_query_string)を追加と呼び出し
check_query_stringの内容
・ポストされた内容より取得したquery_stringを、上記(1)のプログラムで出力したcheck_fileと比較します。
・check_fileにquery_stringと等しいものが存在しない場合→→コメントスパムと判断します。
・check_fileにquery_stringと等しいものが存在した場合
→→IPアドレス(REMOTE_ADDR)をチェックします。
・query_string中の、コメント表示時のIPアドレスと、実際にPOSTされたREMOTE_ADDRが等しい場合
→正しいコメントと判断します。
・コメント表示時と、実際にPOSTされたREMOTE_ADDRが等しくない場合
→コメントスパムと判断します。
mt-comments.cgi
例
呼び出しは、最初に実行されるように。
関数自体は最後のほうに追加するとよいと思います。
##最後のほうに...
## QUERY_STRINGのチェック関数
sub check_query_string{
open (CHECK_F,"/hogehoge/check_file");
my @LINES=<CHECK_F>;
my $query_string = $ENV{'QUERY_STRING'};
close(CHECK_F);
foreach my $line (@LINES) {
if( $line =~ $query_string ){
if ( $query_string =~ $ENV{'REMOTE_ADDR'} ) {
return; ## OK
} else {
my $date = `date +" %H:%M:%S %d/%b/%Y"`;
chop ($date);
`echo "---- spammer info($date) ----"
>> /home/hoge/public_html/spammer.txt`;
`echo "query_string:$query_string"
>> /home/hogehoge/public_html/spammer.txt`;
`echo "posted address:$ENV{'REMOTE_ADDR'}"
>> /home/hoge/public_html/spammer.txt`;
last; ## NG
}
}
print "Content-Type: text/html\n\n";
print "You must comment in the right way.";
exit;
}
いまさっき、このブログが壊れているのに気付きました。
スタイルシートが古いものに戻っていて、
エントリーも古いものに戻っていて(去年の夏ごろ)、
「え~?いまはいつ?私はだれ?....」状態に。
あたま真っ白。
眠たいけれど、データは壊れていないことを確認。全部再構築しなおしました。
#治ってますか?
壊れたきっかけがわかりません。
その時間帯にコメントスパムを受けたのですが...それかしら。
(ただの手入力コメントでした)
なんだか不安定です。
いちおうログを調べて。。。
それから、データベースのバックアップ。
あと、public_html以下のバックアップも取りました。
---追記です----
壊れた原因がわかりました。
#旧ブログへのコメントスパムでした。
www.kiyo.com以下のユーザ下に、昔ここで書いていたブログを置いていたんです。
すっかり忘れていて....笑。
どうやってみつけたのでしょうね?そんな場所。
そこへアクセスしてきちゃったものだから...
パス指定などは、blog.kiyo.comにあわせてあったものだから....
結果、こちらを壊してしまいました。
そのサイトをクローズしたので、もう大丈夫かも。
MovableTypeがスパムメールの踏み台になってしまうそうです。(詳しくはリンク先を...)
昨日、びっくりして上記サイトからプラグインをダウンロードし仕込みました。
(解凍してファイルをひとつ配置するだけです。)
formmail.cgiのセキュリティホールを思い出したのですが、メール処理には細心の注意が必要なのですね。
ますます重たくなるし、ちっともオススメじゃないのだけれど...サイドバーの最近のトラックバックを変更しました。
ちっとも暫定版です。
(はてなアンテナも暫定版のまま、突っ走っているけれど。)
最近トラバされた順に、最大5件のエントリーについて表示するようにしました。
本当はテンプレートだけで実現したかったのだけれど....
プラグインを入れるくらいなら自分でやりたい。
そこで、「私にもできる...」といったら、JSP@Tomcat5.5です。
下記クエリをJSPで実行したものをLynxで読み込んでサイドバーに取り込んでいます。
(1)最近トラックバックされたエントリーをトラックバック日付の降順にmax5件検索するクエリ
select trackback_title
,trackback_id
,trackback_url
from mt_trackback tb
,mt_tbping tbping
where trackback_id = tbping_tb_id
and tbping_created_on =
(
select max(tbping_created_on)
from mt_tbping in_tbping
where in_tbping.tbping_tb_id = tbping.tbping_tb_id
)
order by tbping_created_on desc
limit 5;
(2)それぞれのエントリに対するトラックバックを求めるクエリ
select tbping_title
,tbping_blog_name
,tbping_source_url
,to_char(tbping_created_on,'yyyy/mm/dd') as tbping_created_on
from mt_tbping
where tbping_tb_id = (1)で求めたtracback_id
order by tbping_created_on desc
JSPのソース
いま、pinappleさんからBBSで教えていただいたテンプレートを使って、左側のサイドバーに「最近のトラックバック」を表示しています。これはエントリーの最新順に、トラックバックされたものが表示されているのです。
とても便利になりました!>どうもありがとう!pinappleさん
ここでひとつ問題が...
ずいぶん前のエントリーに、最近トラックバックしていただいんたんです。
それが表示されないんです...涙。
そこで、エントリー付き最近のTrackbackの表示にいつものTomcat5.5(またかよっ)でチャレンジです。
#Tomcat上で動かした結果をSSIで取得するのだ。(←邪道)
とはいっても、サイドバーを表示するたびに毎回動的にjspが実行されてしまうので負荷がかかるし、やってみて納得するだけかもしれません。
「もしかして、Tomcat5.5にWebキャッシュみたいな機能ありましたっけ?あったらいいなぁ~」
「いやまて、もしWebキャッシュできたとしても、Databaseの中身がアップデートされてたら駄目じゃん..」
なんて、余計なこと考えたりもして。
話を元にもどして...
前提条件...MovableType3.01DにPostgreSQLを使っています。
参照するテーブルのチェック
(1)mt_trackback...あらかじめトラックバックを許可している
エントリー毎にレコードが作成される(らしい)。
Column | Type | Modifiers
-----------------------+-----------------------------+-----------
trackback_id | integer | not null
trackback_blog_id | integer | not null
trackback_title | character varying(255) |
trackback_description | text |
trackback_rss_file | character varying(255) |
trackback_url | character varying(255) |
trackback_entry_id | integer | not null
trackback_category_id | integer | not null
trackback_passphrase | character varying(30) |
trackback_is_disabled | smallint |
trackback_created_on | timestamp without time zone | not null
trackback_modified_on | timestamp without time zone | not null
trackback_created_by | integer |
trackback_modified_by | integer |
(2)mt_tbping...トラックバックされたときに作られる(らしい)。
Column | Type | Modifiers
--------------------+-----------------------------+-----------
tbping_id | integer | not null
tbping_blog_id | integer | not null
tbping_tb_id | integer | not null
tbping_title | character varying(255) |
tbping_excerpt | text |
tbping_source_url | character varying(255) |
tbping_ip | character varying(15) | not null
tbping_blog_name | character varying(255) |
tbping_created_on | timestamp without time zone | not null
tbping_modified_on | timestamp without time zone | not null
tbping_created_by | integer |
tbping_modified_by | integer |
(3)現在のmt_tbpingの中身
tbping_id | tbping_tb_id | tbping_title
-----------+--------------+-----------------------------------------------------
10 | 31 | なぜ日記 (のようなもの) を公開するのか
3 | 2 | コメントができないの・・・
4 | 5 | プレビュー画面の不具合修正
6 | 5 | MT3.0コメントプレビューのバグ?
7 | 8 | 文字コードの悪夢
8 | 10 | 今日のアタッカーさん
13 | 6 | MySQLの設定ではお世話になりました。
14 | 36 | フィッシング詐欺にご注意下さい
15 | 83 | New BMW 1シリーズ、国内正式発表10月9日より発売開始!
16 | 83 | BMW1シリーズ試乗
17 | 63 | カスタム・タグを作ろうとしてハマる
19 | 91 | 明日は洗車するぞ~
20 | 83 | ■トートバッグもらえず、、、
21 | 84 | もしかして: 女子高生
26 | 93 | デビューフェアのDMについていたCD、見ました。
27 | 99 | 素敵な彼と彼の音楽
「ほぅ~そうか、もしかして...
mt_trackback.trackback_idと、mt_tbping.tbping_tb_idとが結合できて、
mt_torackback.trackback_entry_idが、mt_entry.entry_idとが結合できるのかな?」
っと予測。
ためしに、上記(3)の一行目のmt_tbping.tbping_tb_id=31から、下記のクエリを実行。
(mt_entryからentry_titleを取ってきました。)
=> select entry_title from mt_entry
-> ,mt_trackback
-> where trackback_id = 31
-> and trackback_entry_id = entry_id;
entry_title
---------------------------------
なぜ、Web上で日記を書くのか??
「エントリータイトルがまったくおんなじっ!!」
『大あたり』だったけれど.....
もしかして...正規化されてない?
entry_titleとtbping_titleの違いってナンですか?
とりあえずのmemoです。
下記のシェルを実行しています。
lynx -source public_html "http://a.hatena.ne.jp/buriburimegurin/source?mode=hina&k=" | nkf -w
はじめ、wgetを使おうと思ったのですが、nkf(文字コードをMTにあわせてutf-8に変換する必要があります)との同期を取る方法がすぐに思いつかないのでとりあえず延期。
こないだインストールしたばかりのlynxを使うことにしました。
#これならパイプを使ってnkfに渡せるので簡単!!
wgetを使って、ローカルファイルに落としておいて、はてな側のタイムスタンプと比較し、
更新されていなければ、取らないっていうのがベストなんですが、はてな側にLast-modifiedヘッダがないのでどーせ出来ないんです。
っというか、とりあえずやってみただけなので、もともと邪道。
XMLを読み込んで、パースして...っていうのが通常のやりかたでしょうか。
ごめんなさい。
先日Lynxでの訪問を発見した時に、このサイトを訪れてくださる方のブラウザについて調べてみたくなりました。
一日一度Webalizerで統計を取っているのですが、デフォルトの設定なのでブラウザはベスト15しか表示していません。
しかも、細かく分かれているため、上位はほとんどMSIE6.0の変形パターンしか出ていません。
今日のお昼休みは、10月3日以降のApacheのアクセスログのUSER_AGENTを調べてみることにしました。
もちろん手作業では無理なので、ここはPostgreSQLにがんばってもらいます。
プログラムを書いてもいいけれど、単純作業でできる方法を考えました。
(1)テーブルを作成
blog=> create table access_log(user_agent text);
(2)Apacheのaccess_logを上記acccess_logテーブルへinsertします。
blog=> \copy access_log from '/***/***/access_log'
(3)何件インサートされたか確認
blog=> select count(*) from access_log;
count
-------
15338
(1 row)
(4)" "(ダブルクオート2つのあいだに半角スペースひとつ)の直後に
USER_AGENTがあるのでsubstr関数でそこから後ろだけにします。
同時に最後の"(ダブルクオート)もtranslate関数で削除。
blog=> update access_log
blog-> set user_agent
blog-> = translate(substr(user_agent,position('" "' in user_agent )+3),'"','');
(5)これでブラウザの種類がaccess_logテーブルのuser_agent列にセットされました。
(6)いよいよカウント順に検索です。
blog=> count(*) as cnt,select user_agent
blog-> from access_log
blog-> group by user_agent
blog-> order by cnt desc;
user_agent | cnt
----------------------------------------------------------------+------
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; istb 702;) | 1877
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) | 1691
----(中略)----
JUGEM-Trackback (http://jugem.jp/) | 1
(243 rows)
うまくいきましたっ!!
結果はhttp://blog.kiyo.com/archives/user_agent.htmlに表形式にしてみました。
いちばん多いのは...きっと私本人のアクセスです(恥っ)。あとはWindows2000ユーザーの息子かも。
(apacheのアクセスログのデータすべてなので、息子のサイトへのアクセスも含まれているのです。)
2番目以降は普通に見ていいと思います:-)。
Lynxでのアクセスはほんの少しです。よく気付いたなぁー>自分(笑)。
OperaやFirefoxもがんばっていますよね!!
また時間のあるときにゆっくりながめたいと思います!
そんな時、エントリー一覧は、カテゴリ別に表示されたほうがよいのです。
少し前に作ったTomcat版のエントリー一覧ですが(サイドバーにリンクをつけました...まだ試験運用版なので、正式ではないのです)、カテゴリの表示順に特に決まりがなかったので気になっていました。
今さっき、やっと、やっと....修正しました。
この並び順のソートの仕方って、最近のコメントのorder順のときにそっくりです。
ひとつだけ、さらに厄介になっているのは、
mt_entry(エントリーの中身の入っているテーブル)
と
mt_category(カテゴリの内容が入っているテーブル)
のほかに、
エントリーとカテゴリをつなげるための
mt_placemnetというテーブルが存在することです。
mt_entryとmt_categoryは直接結合できないんです。
どうも、entry_category_idにはNULLが登録されているようです。
ひとつのエントリーに複数のカテゴリを指定するために、mt_placementが追加されたのでしょうか?
そしてentry_category_idは不要になってしまったのでしょうか?
(なぜ、使われなくなった列を残してあるのかな?)
っというのは、置いておいて....
エントリーとカテゴリを結合させるためには、
entry_id と mt_placementのplacement_entry_id → category_id と mt_placementのplacement_category_id
を結合する必要があります。
それでもって、ひとつのカテゴリに属するエントリーのうち、登録日付が新しいものが含まれるカテゴリを優先して表示しなければならないんです。
っというワケで、↓のようなクエリに落ち着きました。(カテゴリをエントリ登録日時の降順で求めるクエリ)
select category_label
,category_id
from mt_category
,mt_entry
,mt_placement main_placement
where 1 = 1
and entry_id = placement_entry_id
and placement_category_id = category_id
and entry_created_on =
(
select max(entry_created_on)
from mt_entry
,mt_placement sub_placement
where 1 = 1
and entry_id = sub_placement.placement_entry_id
and sub_placement.placement_category_id
= main_placement.placement_category_id
)
order by entry_created_on desc
※「entry_created_onがもしまったく同じ値のエントリーが複数存在したら...」と懸念したけれども、ありえないのでよしとします。上記クエリを入れ込んで検索したのが、現在のTomcat版エントリー一覧です。
リンク先がJSPでエントリー内容を表示しているものになっていますが、blog内の静的なアーカイブへリンクしようかなとも思ってしまいます。
jsp全体のソースはこちらにあります。(加工なしのそのまんまです。)
カテゴリを選択したら、そのカテゴリに属するエントリーの中身じゃなくて、まずはエントリーの一覧が出るようにもしたいな。
ちょっと考えさせられることがあって、コメント投稿時のHTTP_REFERERのチェックをやめました。
#コメントスパムは別の手を使ってくるのがわかったし。
エラーになって投稿できなかった方、本当にごめんなさい。
ただ...まだコメントスパマー用のスクリプトは入れてあるのです。
入力の途中でIPアドレスを変えたりしない限り大丈夫とは思うのですが....。
もし、それでも駄目な場合は....掲示板を設けましたので(左にリンクがあります)、こちらのほうへよろしくお願いいたします。
この週末も雨....
子供たちの勉強につきあいながら、問題のjspのボタン部分のタグの日本語表示ことでも調べようかと思っていたのだけれど(だってStruts1.2.4のサンプルがうまく動いてるんですぅ~)、挫折。
#だって、「さて、やろう」とすると、娘が「みてみて」攻撃してくるんですもん....泣。(←人のせいにしてはイケマセン)
でも、その代わりといっちゃぁ何ですが、個別アーカイブや月別の表示にもサイドバーを設けるようにしました。
「はっ」と、とある方法がひらめいたので....笑。
といっても、たいした方法ではありません。(ぶたないでね~)
例のコメントスパム撃退法と同じで、思いついたことをやっちゃっただけでベストな方法ではないはず。
phpを使ってサイドバーのコンテンツをincludeしちゃえばいいんですけれど、そこは意地でもphpを使っていない私としては(動くのに...笑)、apacheにお願いしちゃうことにしました。
#include virtualを使います。
(1)メインインデックスのテンプレートからサイドバーの部分を切り離して、sidebar.htmlを作って
(2)↓みたいな感じで各テンプレート(メイン、個別、月別、カテゴリー別各アーカイブ)にincludeしちゃいました。
<!--#include virtual="/sidebar.html" -->
表示するときちょっぴり時間がかかるような気がする...(笑)。
そりゃ、最初から固定で作られているよりはかかるのアタリマエだけれど。
ちょっと気になる速さではある...。
(追記)
さて、sidabar.htmlはインクルードされるわけなので、「自分自身の位置」が変わるわけであります。
当然『相対パス』で指定されていたファイルは、各アーカイブから参照された場合、index.htmにいた今までとは場所が異なるので、NOT FOUNDになってしまいます。
「そんなこと、あったりまえじゃない~。わっはっは!」
っと言いたいところが、チェックが甘かったためいくつか取り残しがありました。
っというワケで、sidebarのテンプレートを修正したのですが、修正後、構築しなければならないのは、sidebar.htmlのみであります。
いくつものファイルを再構築しなおす必要はないのです。
ココがポイント。
ココが今回の改修の目的なのでありました。(本当か?まだまだコンテンツ少ないくせに...笑)
コメントスパムのログへのリンクをサイドバーに設けました。
#これでチェックしやすくなります。
それと、ブラックリストの登録のお役に立てれば....
最近のは、一回Postして上手くいかなかったのであきらめた様子です。
でも、IPアドレスは同じ(どちらも66.135.34.87)なので、
「どこのサイトは駄目だった」
などのメモは取っていないようですね。
いい加減破られてしまうかな?と思っていたけれど、
この方法、まだ大丈夫みたいです!!
先日仕込んだとりあえず版のコメントスパム対策ですが、今日みごとにひっかかってくれました。
う、う、うれしい~っ。
#でもどうせ「イタチごっこ」だろうから、そのうち破られちゃうのかなぁ?
9月6日に仕込んだものの、な~んもひっかかってくれなくてさびしかったんです。
それがやっと9日目にしてコメントスパムがやってきました。
そのときのログです。→spammer.txt
コメントスパムのログの1つを例にとります。
---- spammer info( 05:18:47 15/Sep/2004) ----
query_string:damedamespam_051831_150904_mail.gamblingshift.com_66.135.34.87
posted address:64.5.152.67
敵はformに記述しておいたパラメタ(damedamespam_051831_150904_mail.gamblingshift.com_66.135.34.87など)をただしく返してきていました。
ですけれど、POSTするときにIPアドレスを偽装していたのです。
"66.135.34.87"というIPアドレスで、コメントを投稿するFormを表示したくせに、実際にPOSTするときいは"64.5.152.67"になっています。
こんなことやる人、普通いないので、スパマー確定ですよね。
しかも最初の登録時に、
You must comment in the right way.
っと画面に表示されているはずなのに、しつこく6回もトライしているなんて....あきらめの悪い奴です。
対応方法ですが、SSIを使える環境であれば実装できます。
(1)Formタグを表示する場所は2箇所です。
ひとつは、Individual Entry Archiveテンプレート。
コメントを入力していただく部分のformタグに、上記query_stringを出力するSSIの実行を入れます。
もうひとつは、lib/MT/Template/Context.pmです。(確認入力のformはなぜかここで定義されています。)
1220行目付近にformタグの記述がありますので、そこに同じくquery_stringを出力するSSIの実行を入れます。
#CGIで出力した結果に、SSIがあってもちゃんと動作するんですね。
Apacheの設定で拡張子cgiでSSIを動くように設定が必要ですが、本当はとても危険だと感じています(もしかしたらやめるかも)。
確認入力からのPOSTの場合は、スパムのチェックをパスするようにすればよいのかもしれません。
#こんなこと、ここで書いても大丈夫ですよね?
#敵は日本語、読めないですよね?(笑)
(2)SSIとmt-commentsの修正内容については、まったくもってお恥ずかしいスクリプトですし、公開は控えたほうがよいと考えています。
(たぶんいらっしゃらないとは思いますが、興味のある方にはご連絡いただければお返事さしあげたいと考えています。)
(3)MTの管理画面で最初にアクセスしてきたIPアドレス(damedamespamについているほう)をブラックリストに登録すべきです
※POSTしてきたアドレスではないですよ~!!(こちらは単なる踏み台なので)
(追記)
っと思っていたのですが、MTの管理画面で禁止IPに登録しても、通常のアクセスはできちゃうのでしょうか。「コメントやトラックバックの送信元IPアドレスを制限することができます。」
って書いてるので。
じゃぁ、意味がないかも。
すべてのアクセス(閲覧も)禁止!っていう設定はできないのかなぁ??
(さらに自分にツッコミ)
もう、ぼけちゃってますよねぇ~
最初に閲覧されるのは静的なHTMLなんですから、.htaccessででも拒否すればいいですね。
#でも、気力わきません。たいした手間でもないのに、「なぜ.htaccessだと疲れるのか?」謎ですが。
とりあえずモードのチェックをmt-comments.cgiに入れました。
その1)コメントフォームを表示したときのパラメタ(QUERY_STRING)が引き継がれていないと×
その2)引き継がれている場合、その内容がこちらにセーブしたものと一致しなければ×
その3)その内容にはIPアドレスが含まれます。POSTされた時のIPアドレスが一致しなければ×
以上です。
その4)×になった場合はspammer.txtに出力しています。
※一件目は私がテストで実行したモノです。これからが楽しみ....(なんちって)
#あぁ、私ってやっぱり性悪。
これで昨日きたスパムには対応できるはず...
でも....
もし、上手くコメントできない場合がありましたらごめんなさい。
今、コメントスパムの予防策はしていないですが、記録を取っています。
「いつひっかかってくれるかなぁ~」
と心待ちにしていたのですが、今日やっと来てくれました。
#スパムがうれしいなんて、今日くらい(笑)。
わかったことがいくつかあります。
(1)ヤツはダサいことに、ひとつひとつコメントしているらしい。
→だからhiddenに標準でない項目を追加したって駄目なんです。
(2)コメントをPOSTするときだけ、一時的にIPアドレスを変えている。
→ブラックリスト対策かも。これじゃ、いくら禁止IPに登録しても太刀打ち不可です。
(3)でも、ひとまずアクセスするとき(コメントフォームを表示するとき)に使うIPアドレスはだいたい決まっているらしい。
っということです。
一発屋なんかじゃなかったんです。悪さをするとき、一瞬だけIPアドレスを変えていたのです。
ログを晒します。ふっふっふ...(不気味)
まず、コメントスパムを送ってきた人が最初にコメントFormを表示してきたときに使ったIPアドレスです。
コメントスパムは6通あったのですが、対するFormの表示、まんま6回ありました。
私の予想では、一回だけFormを表示して中身をチェックしてから何かツールを使ってばんばんPOSTしてくるのかと思ったら違った....(笑)。
(意外と原始的な方法だったのですね。)
65.75.146.170 host170.easymanaged.com
65.75.166.200 host200.easymanaged.com
65.75.166.210 host210.easymanaged.com
今回使われたのは、この3つのIPアドレスでした。
おそらく、皆様のブラックリストにはこのIPは登録されていないのではないかと思います。
なぜって....このIPでは悪さはしないから。(ただ、コメント用のフォームを表示するだけなので。)
お手軽にコメントスパム対策をするならば、このホスト(easymanaged.com)をアクセス禁止にするといいかも。....でもすぐに別のでくるだろうけれど。
※追記
この3つのホストのうち、
host170.easymanaged.comはオンラインカジノのサイトです。
ほかの2つもサーバはあがっているようです。
オンラインカジノのスパムに関しては、こちらのホストに対してアクセス制限をすればなんとかなるかも。
※追記おわり
※さらに追記
上に、皆様のブラックリストに...というくだり、これは誤りのようです。
どうやら、一瞬IPアドレス変異現象にはいきさつがありそうです。
過去には*.easymanaged.comなんてIPで普通にコメントがPOSTされていたのかもしれません。
それで、いっせいにeasymanaged.comが禁止IPに登録されたものだから、敵は一瞬芸を使うようになった???よーな気がしてきました。
※さらに追記おわり
ひとつだけ例にとって説明します。
(1)敵はまず、http://blog.kiyo.com/archives/2004/08/post_16.htmlにアクセスしました。
※そのとき、Formタグのmt-comments.cgiに下記のようなパラメタをSSIでもって付与しておきました。
damedamespam_15051905_host170.easymanaged.com_65.75.146.170
(2)その後、コメントをPOSTしてきました。
QUERY_STRINGにはしっかり、damedamespam_15051905_host170.easymanaged.com_65.75.146.170が設定されてきました。何も改ざんされていません。そのものです。
ただ、IPアドレスだけは違っていました。
65.75.146.170ではなくて、198.165.90.74 (cache-sp-01.cheznoo.net)です。
アクセスされた日時は"15:05:30 05/Sep/2004"でした。
上のサイトを表示してから、POSTを受付けるまでの時間は、たったの11秒です。
強力プロキシ切り替えツールでも使っているのでしょうか?(笑)
USER_AGENTからは、"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; AIRF)"ということになっているのですが...。
それとも、インターネットオプションの接続のLANの設定を開けっ放しにしておいて、オペレーションしているのでしょうか?(だとしたら笑える)
前回、もしかしたらイケるかも?と書いたあの方法だと、すでにIPアドレスが異なる時点で、このコメントスパムは除去できたワケです。
あとはセーブしておいた情報の保持期間(表示してもすべての人がコメントしてくださるわけでないので)の制御など、考えなくてはなりません。
セッションを使えればいいのですけれどね。アプリケーションサーバが必要になってしまう...やっぱりphpなのかな??
でも、comments.cgi自体はperlなので、コンテンツだけをphpにしても駄目ですね。
とりあえずはセッションなんて考えないで、普通にファイルに保持して、使われない場合は適当な期間で削除していくようにするつもりです。
ただ、この方法にしたって、まともにひとつのIPアドレスで、内容だけがスパムなものをコツコツとPOSTされてしまったらひとたまりもないわけです。
「全部英語だったらスパムと判断する。」
なんていう方法も見かけたけれど、今日、「カジノさん」からPOSTがありました。
敵は日本語も覚えたようです(笑)。
話は変わりますが、スパムメールに下のような内容のものがありました。
最近電話くれないね、嫌いになったの? 彼女出来たのかな?たまには連絡ほしいな。 美香
普通に読んで何も問題のない内容、もちろんSpamAssassinだってスパムとは判断しないし、クライアント側に仕込んだウィルスバスターだって無反応。
Fromアドレスはごくごく普通の一般的なプロバイダのアドレス。踏み台だって使ってやしない。
これと同じで、まともにコメントされちゃって、その内容だけがSPAMじゃね....。
手でこつこつIP禁止指定したって、イタチごっこだろうしね....。
本当、皆さまご苦労さまです...。
※またまた追記
その後、やっぱり気になって"easymanaged.com"でググってみたら、
NET侍さんのサイトがヒットしました。
あれま、host170.easymanaged.comにはアクセスしちゃいけなかったんですね。
ここからリンクしてみた上に、確認のために何回もアクセスしちゃいました。
host200(空白のサイトがあった)もhost210(確かTESTとか出た)も、存在しないホストも試しに...
tracerouteもしたし、pingも打ったし。
わはははは....
もう笑うしかありません。
#ストーリーは決めたものの、まだ仕込んでいないんです。
だって眠たいんですもの。明日は朝早いし、月曜日だし....泣。
大丈夫かな?
※またまた追記ここまで
今日、信号待ちをしながら無意識にコメントスパムのことを考えていた私(←もう病気です!)、ひらめきました。
こういうコトは、そればかりを真剣に考えているときはひらめかないものです。
お風呂にはいっているとき
とか、
電車に乗っているとき
とか、
とにかくぜんぜん違うことをしながら、無意識にボーっと考えているときにひらめくものです。
仕事のことで「あぁ間違えてしまった...まずいっ!!」とサーっと背筋が凍る思いをするのも、電車の中だったりするものです(笑)。
仕事中には気付かないものなんです....悲っ。
さて...、運転していて、
「うーんと、formタグに日時とIPアドレスを入れたんだったっけな。」
「でも、コメントスパムがきたらどうやってチェックすればいいかな?」
「『日時はねつ造してもわかるぞ!』っと確信していたけれど、SSIで表示しているワケだから、POSTされた時間とはもちろん異なるワケだもの...」
よく気付いた!>じぶん(笑)
そこで、その対策として、
「formタグのパラメタを組み立てるSSIの中で、表示するだけじゃなくて、ファイルにセーブしておけばいいじゃん!」
っというコトを思いつきました。赤信号で....(笑)。
んーっと、セーブしておいたのと、POSTされてきたときのQueryStringを比べればいいワケだ。
ほっほっほ!!
等しくなけえば×
等しければ〇
内容はランダムなワケだし。(といっても日時だからな....ぜんぜん関係ない乱数にでもすればもっとわかりにくいかな??でも日時だと自分がログを見たときにわかりやすいもんな~笑)
もいちどまとめると...
(1)コメントを入力する画面のFORMタグにパラメタを追加する(内容は日時または乱数とIPアドレスまたはホスト名)。
(2)FORMタグに追加したパラメタと同じ内容をサーバ上のファイルにセーブしておく。
(3)コメントがPOSTされたら、QUERY_STRINGを取得し、セーブしておいたファイルと比較する。
等しいものがなければNG。
(4)等しいものがあったら、POSTしてきたIPアドレスとパラメタのIPアドレスが等しいことを確認する。
※これは、セーブしておいたファイルに複数データあったとして(このサイトではまずありえないけれど...悲)、どれを見ればいいのかを判別するために、とりあえずはIPアドレスで比較することにします。セッションIDみたいなものと考えればいいかしら?
等しくなければNG。
別にquery_stringじゃなくて、hidden項目にしてその内容を同じように可変にしてもいいのかもしれないですが、環境変数で取れる簡単お手軽方法です。
どちらにしても、これで一発屋はアウトですよね!
これでも、もしコメントスパムが来るとすれば、それは一件一件手でコメントをコピペ入力しているワケで..それもなんだか笑えちゃいます。
......ですよね?
なにかどこか見逃しているかしら??
短い赤信号の時間に考えついたネタなので、あまりたいしたことはないかも(苦笑)
昨日またコメントスパムをありがたくいただいたのです。
対策というのではなくて、「思いつきandいたずら心」で入れていた、damedamespamという文字列が、QUERY_STRINGに見事に仕込まれていました。
敵は何を考えているんだろう?
もしかして、やっぱひとつひとつコメントしてるのかぁ??
たくさんのログを見るのは疲れるのでひとつだけ...。
IPアドレスは211.1.102.67
ホスト名はns.kaichigakuen.ed.jp
....なのだけれど、実在する学校らしいです。
ココをプロキシに設定すると(Portは80)、この学校の中のサイトしか見えなくなります。
#やっぱり偽装だな。
access_logをこのIPでgrepしてみました。
# grep 211.1.102.67 access_log
211.1.102.67 - - [30/Aug/2004:12:37:01 +0900] "POST /mt-comments.cgi?damedamespa
m HTTP/1.1" 500 614 "http://blog.kiyo.com/archives/2004/08/cocosecom.html" "Mozi
lla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; AIRF)"
あら、ひとつしかない....。
まぁもしかして一発屋さん??(笑)
普通、コメントを投稿すると、そのコメントが表示される画面へ遷移するから、
ACCESS_METHOD=GETでもって、__mode=cmtr_name_jsっていう引数でもいちど呼ばれるはずなんですよね。
それがないんです~~っ!
#それでまたちょこっと仕込みました。
#スパム対策にはなっていないけれど、どうやっているか知りたくて。
formタグに日時とIPアドレスが表示されます。暗号化でもすればよいのかもしれませんが、とりあえず素のままです。(SSIを使っています。)
犯人はどういった偽装をしてくるのでしょうか?きちんとセットしてくるのかなぁ~~
やっとやっと、コチラのサイトにもコメントスパムがやってきてくれしました。
#ありがたくはないけれど、
「いっちょまえに来てくれるようになったのね....」
なんて思ったりもして。
HTTP_REREFERは偽装できるというコトでしたが、本当に、「正しい値=コメントをつけるエントリーのアドレス」が設定されてきました。
#私はホスト名の比較しかしていないのでホスト名さえ入っていればPOSTできちゃうんですけれど...。
さて...準備が足りなかった!!
Apacheのaccess_logじゃほかのアクセスログとごった煮状態で見ずらい。
mt-comments.cgiでgrepして別だししてみたりもしたけれど。
そうすると、今度はIPアドレスでまとめてみたくなるし。
なにより、POSTで来ているのでリクエストの中身がわからないし
....っといいつつ、娘の勉強をみながら、ログをしみじみ眺めていたのです。
敵(?)ははじめ、普通にトライした模様。
#Referer未設定でPOSTされた形跡があるのです。
そのあと、HTTP_REFERERを偽装(か、もしくは本当にこのサイトからPOSTしたのかもしれません(笑))してきました。
数個あったスパムはすべて異なるIPアドレスでした。
ホスト名を調べてみると、mail.ほにゃらら....なんてのもあっていったい何者?
きっとIPアドレスはすべて踏み台ですよね。
あらかじめ、エントリーをチェックしたような形跡も...
ホスト名を引けないIPアドレスなんですが、いちどもindexを踏まずに、エントリーを順ぐりに回っているんです。(その直後です、偽装リファラ付コメントスパムが数回。)
でも普通の訪問者なのかもしれないし...。
でもそれにしては、スタイルシートや背景のgifを読んでいないのがアヤシイ....。
USER_AGENT だって、すごくありふれたブラウザのくせして...(これも偽装だろうなぁ)
ツールを使っているにしては回数が少ないなぁ。
ひとつひとつHTTP_REREFERを設定しなおしながらPOSTするから?
それとも人手を使ってコピペ入力しているのか?(じゃないとは思うけれど、本当にそうだとしたら笑える。)
ちょっと対策を考えておくことにします。
明日もまた来るのかしら??
先日、スパム対策も兼ねてHTTP_REFERERをチェックして、自ホストから送信されているコメントのみ受付けるように修正しました。
ただ、ウィルスやワームが氾濫し、多くのPCにセキュリティ対策ソフトが施されている今、Refererはあえて伏せられて送信されることがあるようです。
その場合、悪意がなくてもエラーとなってしまいます。
「だから、MovableTypeはあえてRefererのチェックをしていないのか?」
っというのは置いておいて....
とりあえず、今時点でチェックをはずすのはやめておきました。
なぜなら、私のメインサイトで、このチェックはいつも行ってきたことなんです。
MTを使い始めたのはつい最近のことですけれど、MTにしたからってその方針を変える必要はないかなっと思いました。
でも、いきなり「エラー」じゃあんまりなので、エラーのときに表示される画面にはその旨の説明を入れておきました。
あとコメント入力のところにも、メッセージを入れておきました。
Perhaps you are using a firewall which is removing the http_referer variable when you submit your message. You cannot post without this being available for security reasons.※ファイアウォールや、セキュリティソフトをご利用ですか?※
誠に申し訳ないのですが、当サイトではセキュリティのために、
kiyo.com内からの送信のみ受付けるように設定させていただいております。「Norton Internet Security」などのファイアーウォールソフトを導入して
いらっしゃるパソコンでは、 コメントを投稿時にエラーとなる場合があります。・一時的にファイアウォールを無効にする。
・ファイアウォールソフトの設定を「リファラーを有効にする」にしていただく。などしていただけると、投稿できるようになります。
よろしくお願いいたします。
これでいいかなぁ~....
mt-comments.cgiにHTTP_REFERERのチェックを入れるようにしました。 コメントスパム(スパムコメント)のことがよく話題になっているのですが、私のところにはぜんぜん来ないのです。だから、中身がどんなモノなのか?想像がつきません。
ただ、「コメントスパムを投げるのは簡単なことだなぁ~」と思ってはいます。
だって、本当に簡単なんです。
#何もチェックされていないようなので....。
たとえばデスクトップ上(場所はどこでもいいです)に、これみたいなHTML(URLやエントリーIDは適宜変えてくださいね)を置いて、ブラウザで開いて投稿してみると....
あら不思議、投稿できちゃいます。
MovableType上では、Submitした文字コードすら変換されずにそのまま登録されるので、たとえばUTF-8で運用されているblogに、シフトJISで投稿しちゃったら、化け化けしちゃいます。
#文字化けのことはおいておいて....
ここで何が気になったかというと、
「あっ、MovableTypeのコメント投稿ってREFERERのチェックしてないんだ!」
っということでした。
よくいわれているコメントスパムは、REFERERも偽ってくるのでしょうか?
そこのところがよくわからないのですが、とりあえずチェックを入れておくことにしました。
mt-comments.cgiのはじめのほうに下記のような感じでいれておきました。
これで、上記のやりかたでは投稿できなくなります。
if (!($ENV{'HTTP_REFERER'} =~ /$ENV{'HTTP_HOST'}/) ) {
print "Content-Type: text/html\n\n";
print "<html><head><title>JBad Referer</title></head>\n";
print "<body><center><h1>ERROR: Bad Referer</h1></center></body></html>\n";
exit;
}
※間違ったREFERER(MTを置いているのと異なるホスト)からのアクセスの場合はエラー画面を表示します。
でも、コメントスパムに効き目があるかどうかは、実際にきてみないとわからないです。いろいろな対処方法があるようですので、来たら、そのときまた考えてみたいです。
#...なぁんて悠長なことは言っていられないくらいアタックされるのでしょうか?
たぶん、こんな簡単なことでは防げないのでしょうね。
ただ、
「REFERERについてのチェックについては、どのように認識されているのかな?」
っということについては気になるのググってみました。
"コメントスパム REFERER"で検索をかけたら、mt::MRU 【コメントスパン対策情報】Refererをチェックがヒットしました。
Refererには特殊な文字列が入ってくるようです。これなら、↑の対策で大丈夫そうです。
でもきっとこんなことって「イタチゴッコ」だと思うので、ぜったいに不十分だとは思うのですが。
またこれから、いろいろと考えてみたいと思います。
しつこいです、私...笑。
前回から続きます
distinct ですが、MySQL(3.23.58)だと、並び替えをしないと判明。
(試してみました。『出てきた順』のようです。内部的にソートせずにマージしているのでしょうか?)
PostgreSQL(7.3.4)はdistinctした列でソート(並び替え)が行われます。(だから今回の不具合が出ました。)
ちなみにOracleもPostgreSQLと同じです。
今回の問題、
mt_commentと、mt_entryの結合にあると思うのです。
ER図にしてみました。

まず、最近のコメントを持っているエントリーを検索しなければなりません。
最近のコメントを取るためには、MT_COMMENTの中の、COMMENT_CREATED_ONで判断します。
エントリ(MT_ENTRY)と、コメント(MT_COMMENT)は、ENTRY_IDとCOMMENT_ENTRY_IDで結合されます。
エントリと結合するコメントのうち、いちばん最新のものを持ってきて、それをCOMMENT_CREATE_ONの降順でOrderするんです。
それで↓のようなクエリをかけたらいいのでは?っと思っていたのです。
select
entry_id
,entry_title
,comment_author
,to_char(comment_created_on,'yyyy/mm/dd')
from mt_entry
,mt_comment cm1
where entry_id = comment_entry_id
and comment_created_on =
(
select max(comment_created_on)
from mt_comment cm2
where cm2.comment_entry_id = cm1.comment_entry_id
)
order by comment_created_on desc
limit 5
(結果)
id | entry_title | author | comment_create
----+---------------------------------+--------+----------------
36 | PostgreSQLへ...その4?? | (o) | 2004/08/13
35 | PostgreSQLへ....その3 | megu | 2004/08/13
26 | なぜ、Web上で日記を書くのか?? | megu | 2004/08/10
23 | 管理画面のアクセス制限 | megu | 2004/08/10
25 | Audi newA6見てきました | megu | 2004/08/04
(5 rows)
相関副問い合わせを使っています。
副問い合わせ内では親問い合わせで取得したエントリIDのデータ中
いちばんcomment_created_onの値が大きいものを取り出します。
#しかしながら、私の力ではこれをどーやってMTに載せればよいのかわかりません。
#こういった問い合わせは無理があるのかも。
それで、教えていただいた、mizさんのパッチですが、
ありがたく更新させていただきました...m(_ _)m。
↓はmizさんのパッチをあてさせていただいた後のSQLです。
select entry_id,
entry_blog_id,
entry_status,
entry_author_id,
entry_allow_comments,
entry_title,
entry_excerpt,
entry_text,
entry_text_more,
entry_convert_breaks,
entry_to_ping_urls,
entry_pinged_urls,
entry_allow_pings,
entry_keywords,
entry_tangent_cache,
entry_basename,
entry_category_id,
entry_created_on,
entry_created_by,
entry_modified_on,
entry_modified_by
from
(
select
entry_id,
entry_blog_id,
entry_status,
entry_author_id,
entry_allow_comments,
entry_title,
entry_excerpt,
entry_text,
entry_text_more,
entry_convert_breaks,
entry_to_ping_urls,
entry_pinged_urls,
entry_allow_pings,
entry_keywords,
entry_tangent_cache,
entry_basename,
entry_category_id,
entry_created_on,
entry_created_by,
entry_modified_on,
entry_modified_by,
max (comment_created_on)
as entry_comment_created_on
from
mt_entry,
mt_comment
where (comment_blog_id = ?)
and (comment_visible = ?)
and entry_id = comment_entry_id
and (entry_blog_id = ?)
and (entry_status = ?)
group by entry_id,
entry_blog_id,
entry_status,
entry_author_id,
entry_allow_comments,
entry_title,
entry_excerpt,
entry_text,
entry_text_more,
entry_convert_breaks,
entry_to_ping_urls,
entry_pinged_urls,
entry_allow_pings,
entry_keywords,
entry_tangent_cache,
entry_basename,
entry_category_id,
entry_created_on,
entry_created_by,
entry_modified_on,
entry_modified_by) t
order by entry_comment_created_on desc
limit 5
相関副問い合わせのかわりに、
From句の中にさらにSELECT命令、
その中でグルーピングして、各々のエントリーの中でcomment_created_onのいちばん大きいものを取り出しています。
コメント日付のいちばん新しい行を取ってくるViewを作成したのと同様だと思います。
(この場合、検索条件が内側のSELECT(=view)に含まれているので懸念される検索速度の低下には繋がらないと思いますが、メインカーソルで条件を絞り込んだ上で、その結果に対して副問い合わせを行ったほうがよい場合もあります。)
きっと、MTに実装するには、これがいちばん良い方法なんだと思います。
ソースと照らし合わせみると
「ほぅ~、こうやって書くのね」
と、思うのですが
じゃっ、いざ自分が考えていたクエリを実行させるにはどうすればいい?
#ちょっと時間をかけて考えたいとは思うけれど。
なんだかとってもわかりずらいソースプログラム。
もともと、MTのテーブルはフクザツな関係は持っていないと思うのです。
唯一、ちょっと難しい検索を使っているのがこの部分(最近のコメント)だったのではないでしょうか?
ではなぜMySQLではSQLの組み立て部分が異なってくるのか?
できれば同じ問い合わせを使うほうがいいに決まっているのに....なぁんて思ってしまうのですが...。
バージョンによるのかもしれませんが、私のMySQL(3.23.58)では、相関副問い合わせをかけようとすると、エラーとなります。From句にSELECT命令を書いても駄目です。
副問い合わせも駄目でした。
5.0のマニュアルでは出来るようなこと書いてあるのですが...
おそらく、普及しているであろうバージョンのMySQLにあわせると、副問い合わせを使うわけにはいかないのでしょう。
あまり悩んでいても本来の目的からかなり脱線してしまっているので、
このくらいにしておいたほうがいいのかも??
いろいろあった文字コード、PostgreSQLだったらクリアできそうな感じ。
※PostgreSQL 7.4.3 文書..20.2. 文字セットサポート参照
Slackware時代に愛用していたRDBMSだし、
「いいんじゃないかな??」
っと突然思い、入れることにしました。
インストール、設定は↓を参考に
http://www.postgresql.jp/document/pg743doc/html/admin.html
以下箇条書きのメモになります。
(1)ダウンロード
# wget ftp://ftp.postgresql.org/pub/v7.4.3/postgresql-7.4.3.tar.gz
(2)展開
# tar xvfz postgresql-7.4.3.tar.gz
(3)make
# cd postgresql-7.4.3
# ./configure --with-perl --with-java --enable-nls='ja'
--with-perl....PL/Perl サーバサイド言語を選択してみました。
(PL/SQLのPerl版?なんだろう?)
--with-java....JDBC経由でのアクセスは必須なので。
--enable-nls='ja'....メッセージの表示を日本語で。
※--enable-muntibyte というパラメタ、7.4.3ではマルチバイト処理が
含まれているので不要になったそうです。
# gmake
※注意です。GNU makeを使います。
時間がかかると書いてありますが、本当にかかりました(汗)。約15分。
上記説明サイトには「5 分から 30 分くらいかかります。」のでまぁまぁの成績かしら?(笑)
# gmake install
(4)ユーザーの作成
# useradd postgres
(5)所有権の変更
# chown postgres.postgres -R /usr/local/pgsql
/usr/local/pgsqlの所有者がrootになっているので、上で作成したpotgresユーザーに変更します。
(6)posgresユーザーの環境変数設定
.bash_profileに追加しました。
export PATH="$PATH":/usr/local/pgsql/bin
export POSTGRES_HOME=/usr/local/pgsql
export PGLIB=$POSTGRES_HOME/lib
export PGDATA=$POSTGRES_HOME/data
export MANPATH="$MANPATH":$POSTGRES_HOME/man
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH":"$PGLIB"
$ source .bash_profile で反映させます。
(7)データ領域の作成
$ initdb -E UNICODE
※オプション -D を使う代わりに環境変数 PGDATA を使っています。
上記(6)の設定より、/usr/local/pgsql/dataになります。
データベースに格納する文字コードはUNICODE(utf-8)で、
クライアントからアクセスするときの文字コードはEUCと指定して行うことに決めましたっ!
Success. You can now start the database server using:
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
or
/usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
成功!:-)
(8)データベースを起動
$ postmaster -D /usr/local/pgsql/data >/usr/local/pgsql/logfile 2>&1 &
(9)データベースをシャットダウン
$ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`
(10)システム起動時にPostgreSQLが起動するように設定
/etc/inittabに、下記行を追加
pg:2345:respawn:/bin/su - postgres -c
"/usr/local/pgsql/bin/postmaster -D/usr/local/pgsql/data >>
/usr/local/pgsql/logfile 2>&1 </dev/null"
(メモ)
Java(JDBC)パッケージ群が必要な場合(--with-javaを指定する場合)
ant(jakarta.apache.org参照..Java環境におけるMakeツール)が必要です。
インストール手順 解凍して環境変数を整えるだけです。
# wget http://sunsite.tus.ac.jp/pub/apache/ant/binaries/apache-ant-1.6.2-bin.tar.gz
# tar xvfz apache-ant-1.6.2-bin.tar.gz
$ANT_HOMEを解凍後のapache-ant-1.6.2ディレクトリに設定。
$ANT_HOME/binにPATHを通す
私は、postgresユーザーにJavaは必要ないので(いいのかな?)
普段Jakartaプロジェクトツール(TomcatなどJavaアプリ)を利用しているユーザでログインしてから、rootにsuしてconfigureしました。
今日はインストールまで。
これから、mysqldumpで吐き出したSQL文をPostgreSQLに読み込ませて、
MTの設定をPostgreSQLへ変更する予定です。
さてどーなるか....
投稿者 megu : 12:55
MT3.01を新規にインストールしたあと、.htaccessファイルの設置を忘れていました。#どこからでも誰からでもアクセスできちゃっていましたね(^^;;;
mt.cfgも....mt.cgiも...
駄目よ、見ちゃ!!>そこの貴方!!
余計なcgiも入ったままでした(^^;;; いけない、いけない...
これらはtoolsというディレクトリに移動しちゃいました。(別に削除してもかまいませんが)
$ mv mt-db2sql.cgi ../tools
$ mv mt-load.cgi ../tools
※ダウンロードしてきた、MTのtar.gzファイルをローカルなPC環境であらかじめ解凍してから、FTPでアップロードされる方は、アップロード自体をしないのでしょうね。
でもサーバーサイドで解凍していらっしゃる方は要注意です。
新規インストールは、こういうコトを忘れやすいので気をつけなくてはなりません。
(って私だけですか?)
アクセス制限は自前のサーバなのでhttpd.confでも出来るのですが、私は.htaccessで対応しています。
.htaccessの内容は下記のようにしています。
<Files mt.cfg>
<Limit GET>
deny from all
</Limit>
</Files>
<Files mt.cgi>
<Limit GET>
Order deny,allow
deny from all
allow from 192.168.1.0/255.255.255.0 ←ローカルアドレスからのアクセス
allow from ***.***.***.*** ←自分が使うであろうGlobalIPアドレスを設定
allow from ***.***.***.*** ←(複数設定できます)
</Limit>
</Files>
上記設定で、管理画面は許可されていないIPアドレスからはアクセスできなくなります。
コンフィギュレーションファイル(mt.cfg)は、すべてのIPからアクセスできなくなります。
ほっ。
※今日の晒しモノ(どこの誰ですか?うちにアクセスしようとした人!!)
Aug 3 08:20:41 megu sshd[24747]: refused connect from 211.138.142.26 (211.138.142.26)
今日、やっとこさメインインデックスや、スタイルシートなどのテンプレートをいろいろさわってみました。
#私らしくもない...笑。
っというのは、こういった作業がすっごく苦手なんです。
デザイン関係、まるで駄目です。センスなし。
女性らしくないですね(苦笑)。....そうなんです、私、実は♀だったんです。
って、このピンクピンクしたBGカラーや、言い回しやハンドルでとっくにバレているかもしれないけれど。
デザインはともかく、機能としてどうしても欲しかったのが、エントリーの一覧でした。
だって、いつ何をエントリーしたのか忘れちゃうんですもの。
もちろん管理画面からは見えるけれど、データをUTF-8にしてしまった今、
mysqlコマンドで見ることはできなくなってしまいました。
#やっぱ、便利だったかも....EUC-JPのままにしておいたほうが、、、、
並べ替えも、絞込みも自由自在だものねぇ~~
でもそんなことないわ、きっと!!←自問自答しています(笑)
OSはEUC-JPベースで動いているけれど、MySQLだけでもUTFにしてみるか?
....なんて可能なのでしょうか??Oracleだったら可能なのはわかるけれど。
(っと、またなにげに『教えてチャン』している自分。駄目駄目)
話がそれてしまいました。
テンプレートの更新ですが、
見た目ばかりのスタイルシートの更新は、いつも通りサーバに直接ログインして、エディタでどんどん直しながら確認しました。
そのほうが断然速いです。
Telnetを使えないプロバイダをご利用の方でも、例のWebdavを利用してスタイルシートを直接更新することが出来る場合もあるのではないでしょうか?
なかなか便利ですよ~
「上書き→リロード」で即座にサイトの確認を出来るので。
MainIndexはそうもいかないので、保存→再構築で確認の繰り返しでした。
そうこうしているうちに、なんとなく....あくまでもなんとなくですが、テンプレートの使い方みたいなのがわかてきたような気がしました。
正式に時間をかけて勉強したワケでもないのでかなりいい加減かもしれないですが、
『もしかしてこういうのできる?』
と思って試したらできちゃったり....っていう感じでエントリー一覧が出来上がりました。
うーん、初オリジナルテンプレートでとってもうれしい自分です:-)。
#もう、こんなの慣れた人からみたら笑われちゃうかもしれないけれど...。
少しずつですが、エントリーもwww.kiyo.comのほうから転載してきています。
転載し終えたら整理して、サイトをひとつにまとめようかなっと思っています。
その頃にはカテゴリも増えて、も少しブログらしくなれるでしょうか??
....なりたいです...
追記
んで、今さっき気付いたんですが、archives.htmlって、デフォルトで出来ていたんですね。
まったくトホホでごじゃりまする....。
まっ、いいかっ。
文字コードをEUC-JPからUTF-8に戻しました。
MTを入れたとき、最初はUTFでしたが、
「サーバの文字コード(EUC-JP)と一致していなくて不便」
と、EUC-JPに変更しました。
Databaseを直接さわっていろいろ出来て便利でした。
でもやはり、MT3.0にはUTFのほうがしっくり来るような気がしたのです。
これで、メールのタイトルも文字化けしないようになったし。
もう、SQLで直接コンテンツを修正することもなくなるでしょう(笑)。
移行の手順ですが、今回はMovable Type の文字コード変換スクリプトは使いませんでした。
#もう"~"や"-"の文字化けで悩むのいやだったし...
mysqldumpコマンドで吐き出されたsql命令に対して、nkfコマンドでutfに変換しました。
それから、新しく使用するDatabaseに対してそのSQLを実行しました。
バックアップしたSQL文中にもともとUTFコードのものがあったのは予想外で、その部分だけエラーになりましたが、すぐに気付いたので修正はカンタンでした。
UTF-8→EUC-JP
よりも
EUC-JP→UTF-8
のほうがすんなり簡単に処理できると思います。
同時にMT3.0は正式版に乗り換えました。
これは、アップグレードではなくてフルインストールしました。
別ユーザーでフルインストールして、UTFに変更後のSQLを読み込むようにmt.cfgで指定し管理画面を立ち上げました。
テンプレートの修正など完了してから、こちらへ移動してきました。
テンプレートに関しては、今回すこ~しだけですがわかってきたような気がします(笑)。
#これ、やりはじめるとハマりそうですね。
まだまだヒヨッコですが....。
今からやりたいことですが、「はじめて」を取ったので、MTに関することばっかりではなくて、いろいろなことアップできたらと思っています。
愛車つながりでリンクもしていただけたし、「がんばらなくちゃなぁ~!」って感じです。
プロフィールも、いつまでも工事中にしておかないように!!<自分
カテゴリを登録したので、今までのエントリーを分類しようと思いました。でも、上手くいかないんです。
原因は直接MySQLを更新してしまったから?
それだけではないと思うのですが....
エラーがでます。
原因がわかりました(笑)
MySQLなんて、ぜんぜん関係なくって、
ウェブログの設定>アーカイブの設定>アーカイブ のカテゴリーがチェックされていないままでした。
これじゃいくら、データで「関連づけるよ」といっても駄目なんですね....。
データ側(MySQL)でのカテゴリの関連付けは下記の方法でOKでした。
ただ、管理画面から一括更新できるようになっていることにあとで気付きました。
私の環境ではDBを更新したほうがうんと速いですが、管理画面がサクサク動く環境でしたら、そちらで更新されるとよいと思います。
(というかそちらのほうがまっとうなやり方だと思います。)
SQLでのカテゴリとエントリーの関連付けの覚書
mysql> select category_id,category_label from mt_category;
+-------------+--------------------+
| category_id | category_label |
+-------------+--------------------+
| 1 | MTについてあれこれ |
| 2 | セキュリティー |
| 3 | MyAudi |
+-------------+--------------------+
3 rows in set (0.00 sec)
※mt_entryテーブルのentry_category_idをすべて1に更新した後、うまく
表示されなかったので、検索してみました
mysql> select entry_title,entry_category_id as cat_id
-> from mt_entry;
+-------------------------------------------------------------+--------+
| entry_title | cat_id |
+-------------------------------------------------------------+--------+
| Movable Type 3.0 Developer Edition日本語版ベータ 設定時メモ | 1 |
| コメントのプレビュー の問題、 画像のサムネイル | 1 |
| スタイルシート | 1 |
| (続)スタイルシート | 1 |
| コメントプレビューの不具合修正について | 1 |
| formmail.cgiのセキュリティホールを狙った攻撃 | 1 |
| MySQLへの移行..あれこれ | 1 |
| 今後の課題....文字コード変換など | 1 |
| 文字コードの変換をやってみた | 1 |
| 内部はEUCでも、Webサイト側はUTFで構築...って出来ない? | 1 |
| 最近のコメント? | 1 |
| MT3.0DEのコメント登録エラー | 1 |
| 文字コード、UTF-8に戻そうかな? | 1 |
| とりあえずはEUC-JPのままで文字化けを修正 | 1 |
| ブログ名を変えてみました | 1 |
+-------------------------------------------------------------+--------+
15 rows in set (0.01 sec)
※mt_placementというそれらしきテーブルをみつけました。
mysql> describe mt_placement;
+-----------------------+------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+------------+------+-----+---------+----------------+
| placement_id | int(11) | | PRI | NULL | auto_increment |
| placement_entry_id | int(11) | | MUL | 0 | |
| placement_blog_id | int(11) | | | 0 | |
| placement_category_id | int(11) | | MUL | 0 | |
| placement_is_primary | tinyint(4) | | MUL | 0 | |
+-----------------------+------------+------+-----+---------+----------------+
5 rows in set (0.01 sec)
mysql> select * from mt_placement;
+--------------+--------------------+-------------------+-----------------------
+----------------------+
| placement_id | placement_entry_id | placement_blog_id | placement_category_id
| placement_is_primary |
+--------------+--------------------+-------------------+-----------------------
+----------------------+
| 1 | 16 | 1 | 1
| 1 |
+--------------+--------------------+-------------------+-----------------------
+----------------------+
1 row in set (0.00 sec)
※やっぱりコレだということで、追加登録しました。
mysql> insert into mt_placement
-> (
-> placement_entry_id
-> ,placement_blog_id
-> ,placement_category_id
-> ,placement_is_primary
-> )
-> select
-> entry_id
-> ,1
-> ,1
-> ,1
-> from mt_entry
-> where entry_id != 16;
Query OK, 14 rows affected (0.00 sec)
Records: 14 Duplicates: 0 Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
※2004.08.01 追加
文字コードをUTF-8に変更しました。
そのため、↑のSQLの表示の□の部分が崩れてしまっています。
ブログ名は、管理画面からどうやって変更するのかわからないのですが、
Databaseの中を変更すれば変わるんじゃないかと思っていました。
※やってみたら変わりました(笑)
文字コードをUTF-8に戻してしまったら、EUC-JPなMySQLからは上手く更新できなくなってしまいます。
それで、エイヤっと変更してみました。
「はじめてのウエブログ♪」から「はじめての」は取ろうかなと考えていたのですが、そのほかには何も思いつきませんでした。
だからとっても安易なブログ名...。megu's blogになりました。(これならUTFでも見えるし!笑)
「はじめての」が取れたといっても、いつまでたっても進歩していないんですけれどね....私。
もっともっとテンプレートとか見なくちゃいけないし、管理画面もいろいろさわってみればいいの、わかっているけれど...。
さて、ブログ名の変更方法です。
MySQLの場合ですが、mt_blogというテーブルの、blog_nameという列を更新します。
下記は、"はじめてのウエブログ♪"というブログ名を"megu's blog"に変更した例です。
mysql> update mt_blog
-> set blog_name = 'megu''s blog'
-> where blog_name = 'はじめてのウエブログ♪';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0mysql> commit;
Query OK, 0 rows affected (0.00 sec)
実際にこの更新を行った後、管理画面にログインすると、新しいブログ名が表示されます。
サイトの再構築をすれば、サイトにも反映されます。
P.S.
リンクしてくださっている方、ブログ名がかわってごめんなさい。
これからもどうぞよろしくお願いいたします。
文字コードをUTF-8に戻す前のstepとして、
とりあえずは以前、UTF-8からEUC-JPに変換した際に文字化けしてしまった分を修正してみました。
もうコンテンツ中の表示できない文字(†)はなくなっているはずです。
修正対象は「〜」と「−」の二文字ありました。
どちらもCP932の変換テーブルの相違が原因だと思いますが....。
今後UTF-8に戻したなら、
入力→保存→表示
がすべてUTF-8で行われるので変換上の問題はなくなると思います。
ただ、TrackbackのリクエストがEUCでPOSTされてきた場合の変換には問題が残るかもしれません。
(これは、変換後に試してみます。)
いったん、EUC-JPに変換した文字コードですが、所々に不都合も見られるのでUTF-8に逆戻りしてみようかなと考えつつあります。
OSやDatabaseと同じ文字コードを使うようにすればメンテナンスが楽かなと考えたのですが、直接メンテというのもめったにないことだと思うし....
#そうそう、できればMySQLに登録したコンテンツをBerkeleyDBに戻したいです。(理由はバックアップがカンタンだから....だけではないけれど)
考えている戻し方は、そんなに難しくはありません。
前回と逆のことをやるだけ。
(1)mysqldumpでMySQLからデータをInsert文として出力する。
(2)出力されたInsert文をnkfコマンドで、UTF-8に変換する。
(たぶん、これがいちばんうまくいくと思います。前回もnkfコマンドによる変換では〜の文字化けも発生しませんでした。)
(3)いったん、テーブルを初期化し、その後変換後のsqlを実行する。
(4)mt.cfgのPublishCharsetをUTF-8に戻す。
やればすぐ(のはず)なのに、なかなかできないのは、私だから....(笑)。
#MySQL→BerkeleyDBの移行方法はまだ調査中デス。
Movable Type 3.0 Developer Edition日本語版、出ましたね。
なぜかあまり話題になっていないような気がするのですが、私のテストサイトではコメント投稿でエラーがでるので、まだこちらの入れ替えに踏み切っていません。
#MT3.0DE正式版に乗り換えになられた皆様
コメントの登録が失敗しました:
The validation failed.
なんてのが、出ませんか??
これ、最初のベータ版には出なかった現象で、ベータ2からではじめたんです。
本当は.....私がもう少しわかってきて...
「はじめての」が取れる頃に、毎日毎日viエディタでごりごりと編集しているメインサイトをMT化して楽しちゃおうとも思っているのですが、そこまで到達するにはもうしばらくかかりそうです。
(追記 2004.07.27)
この問題に関して、コメントをいただき、テンプレートの差し替えが必要なことがわかりました。
#(o)さん、いつもありがとうございます!
前に出ていたコメントのプレビューの問題もあわせてクリアされるわけですね!
今度、正式版に乗り換えたいと思います。
それから、(私のことだからいつになるかわからないけれど....もう、すみません)メインサイトのMT化もやっぱりやりたいです。
今日、トップにな〜んも表示されていないことに気付きました。
長らく更新していないからだなぁ....とは思ったけれど、
「んじゃ、INDEXが更新されたトリガはなんだったのだろう?」
と思いました。
コンテンツの中から更新されたファイルを探しました。
おぉ〜!!見つかった!!
ありがたく、トラックバックしていただいていました。
#本当にどうもありがとうございます....こんなつたない場所にトラックバックしていただいて...m(_ _)m
ところで....
(本当に、私って....タコで、申し訳ないのですが、)
コメントをいただいたり、トラックバックしていただいた場合、デフォルトのテンプレートのまんまで右下あたりに「最近のコメント」とか、「最近のトラックバック」とか、表示されていたような気がしたのですが、本当のところはどうでしたっけ??
「もしかして少し前にリンクを付け足したときに消しちゃった?」
とか思って、過去のバックアップをひっくり返してみたけれど、やっぱり「最近のコメント」なんてのは存在しなかったです.....(思い違いだったのかしら??)
文字コードをUTF-8からEUCへ変換したのはいいのですが...
ふと冷静になってみると...
「私、なんか逆のことやってない?」
ってキモチになりました。
確かにEUCになって、システムとシームレスになって便利になりました。
エディタで開いてもちゃんと見えるし、SQLでもちゃんと見えるし...
ちょっとした更新なら、DBを直接....たとえば
「テンプレートの更新、管理画面を介さなくても出来るようなツールを作ろうかな」
とか欲も出てきました。
でも....なぜ、せっかくUTF-8で表示していたものをEUCにしなくちゃならなかったのか??
世の中の流れは、Unicodeじゃないのかなぁ〜〜 っと...。
そもそも、
1.データベース内の文字コード
2.システムで使う文字コード(ソースコードの中の文字コード)
3.公開するときの文字コード
上記は別のものであっても、よいのでは??と思ったのですが....。
私の環境だたら、
データベースとソースはEUCで、
最終的に構築するサイトはUTF-8で....っというのがベストだと、、、
よく考えてみれば(考えてみなくても?)、そうすることがアタリマエのことのように思えてきました。
なぜ、全部同じじゃなくちゃいけないのか?
そりゃ、それがMTにとって都合がよいからだろうけれど。
...などではなくて、おそらく.....
まだ私の勉強が足りないせいなのだと思います。
(構築時に指定された文字コードに変換なんて、jcodeかけちぇばいいだけですから、簡単にできそうですもんね。)
MTをきちんと研究せずに「とりあえずモード」で使っているから。
もしかしたら、どこかに「設定ファイル」があるのかもしれません。
少し探してみます。
あとひとつ...
文字コードを変換する前、DBの中、UTF-8でした。
ほとんど日本語(2バイト文字)のここのコンテンツをUTF-8で保存するのにはギモンがありました。
たとえば、Perlのソースコードの中にポツポツと日本語(2バイト文字)が出てくるような場合はUTF-8が(格納サイズという意味で)効率が良いと思うのですが、エントリーの内容など、どうみてもほとんど日本語。
絶対UTF-16のほうが効率がいいですよね。
いろいろ考えると、やっぱり、文字コードの使い分けができるのがいちばんいいのかな?
っと思います。
<追記>
mt.cfgのPublishCharsetですが、コメント部に
#Use the PublishCharset option to determine the character encoding that is sent in the HTTP headers.
と書いてあるんです。
「出力するときにこの文字コードセットを使いますよ」
と言っている風に受け取れなくもないので、ちょっと期待して、UTF-8にしてみました。
『もしかしたら、内部のEUC-JPは勝手に判断してくれて、構築する際にUTFに変換してくれないかな』
という、あまい期待を抱いて..
結果は.....

文字ばけちゃいました(泣)。
う〜ん、甘かったです。
PublishCharasetはEUC-JPに戻してやりなおし....。
どのようにすれば、うまくいくのだろう。
あと、UTFコードでのTrackBackを正常に受け取れるか気になったのでテストしてみました。
トラックバックpingの送信はHTMLを使って簡単にできます。
UTFコードでテスト用のサイトを作って、このエントリーへトラックバックしてみましたが正常に表示されているので、ひと安心です:-)
トラックバックテスト用サイトです。
MySQLのデータをセーブする方法、いろいろあるのかもしれませんが、
mysqldumpというコマンドを使って、
