[xoops] xmobile 書込みが protectorでスパム判定される
- このフォーラムに新規トピックを投稿できます
- このフォーラムではゲスト投稿が許可されています
投稿ツリー
- [xoops] xmobile 書込みが protectorでスパム判定される (なーお, 2007/10/13 1:23)
- これでどうかな?(Re:xmobile 書込みがスパム判定 (なーお, 2007/10/15 21:33)
- だめか??(Re:testing) (なーお, 2007/10/15 23:41)
- だめじゃん(Re:xmobile& protectでスパム誤判定) (なーお, 2007/10/16 13:16)
- これもだめ(Re:xmobile& protectスパム誤判定) (なーお, 2007/10/17 7:52)
- これでいいかナ?(Re:xmobile& protectorスパム誤判定) (なーお, 2007/10/19 8:47)
- Re: [xoops] xmobile 書込みが protectorでスパム判定される (長さん, 2009/4/25 17:04)
- Re: [xoops] xmobile 書込みが protectorでスパム判定される (なーお, 2009/4/26 18:17)
最近は、インターネットもパソコン無しで携帯だけで活動している人も多いようでして、xoopsで構築したサイトで、携帯対応として「xmobile」を活用しています。
一方、古くからあるモジュール、あるいはそれをベースとしたモジュールは、独自のスパムブロックを持ち合わせていない場合が多いのが実情です。
特に、海外からのスパムは目を覆うほどにひどく、頭を悩ませていましたが、 「protector」という包括的にxoopsサーバーに作用できる便利なモジュールがあることを知り、その「postcommon_post_need_multibyte_.php」 というプラグインを使ってみました。
これで確かに、日本語を含まない海外からのスパムはブロックされるのですが、どうもxmobileの携帯からの書き込みが、日本語として認識されずに書き込めない、という問題に遭遇して困っていました。
そんなとき、ググッいたらようやくここにたどり着きました。
しかし、、これでもだめです。
「contact」モジュールへのメール送信は可能なのに、「xhnewbb」へのコメントは蹴られます。 これはxoops-cube2.1用の情報でした。
結局、postcommon_post_need_multibyte.php の中の
1 2 3 4 5 6 |
|
の 0 => 100 を 0 => 150 にしたらOKになりました。
これって、URL文字列の文字数がこの値以上だったら、その中の文字列を判定する、ということだったのだと、やっと気づいた。
つまり、この値未満の文字数の(日本語を含まない)トラックバックスパムは防御できない
??>>
この値を増やしたことで、防御できないトラックバックスパムも増えるワケですな。
あー、チカレタ。
どうもこのプラグインの挙動が気になります。
このロジックだと、 100文字(Defo時)以上の文字列の中に日本語がなければ、即スパム扱いです。
ところが、xmobileなどURL文字列が長い場合には、例え本文に日本語が書いてあっても、日本語が1文字も無いURLの段階で判断され、スパムと判定されてしまいます。
ループ抜けの判定は、「日本語があること」としておき、日本語があるときはフラグを立て、 ループ外でフラグの有無を評価する方が良さそうだけど。。 この考え、間違っているかなあ・・
***
で、こんな感じかな。。
一応、テストはしてみたけど、判定文字数下限値を、「100」を「40」にしても正常に日本語判定したし、日本語の無い書き込みはハネてくれた。
元のコード
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
変更後のコード
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
PCからだと、書けてしまった。。
やっぱりこの方法では、だめか。
追記
フォーラムのゲストの文字列設定を「ゲスト」→「Guest」にしたら、きちんとブロックしてくれました。 自動で入る文字なのに判定されちゃうのか。
再度追記
外部のPCでログインができなくなったので、元に戻しました。
処理が理解できていないので、勉強してから出直しです。
電車の中で気づきました。。 これだと判定文字数以上の文字列がないと、全てスパム判定ですね。 ログインが失敗するのも当然。 (恥)
「判定文字数以上」フラグを作って、判定文字数以上=true & multibyte_ok判定フラグ=false でスパムとすれば良いのかな。
今晩にでも、やってみます。
下のコードでも、だめ。
自分で分かりやすいように愚直に書いてみたけど。。
・・singlebyte投稿がスルーしちゃう。
うーん。。 これ以上はローカル環境を作らないと、無理だなあ。virtualマシンごとコピーして、ドメインを割り当てて・・ 出張族には厳しく、少し時間がかかりそうです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
|
結局、上のロジックの判定文字列数下限値を「80」とし、更に150以上のsinglebyte文字列があれば無条件にアウト、にて様子を見ています。
・文字数が150以上:日本語文字が無いデータが1つあればSPAM(下表の「拒否3」)
・キー名称が'message','com_text','excerpt'で日本語文字がある2文字以上データが1つあれば許可(「許可1」)
・文字数80以上150未満:日本語文字があるデータが1つあれば許可(「許可2」)
ループを抜けた段階で「拒否」が優先処理され、「許可」も「拒否」も無いばあいは
(1)判定文字数以上の文字列が無かった場合は「許可」
(2)判定文字数以上の文字列が有った場合「拒否」となる。
まとめると、以下の感じです。
1 2 3 4 5 6 7 8 |
|
d3forumでスルーになった原因は、返信フォームのpost文字列中に「引用」用の文字列がそのまま割り込んで送信されてくるため、上記表の「許可1」の部分に当たったのでした。
singlebyteスパムのほとんどはロボットでしょうから、その場合は「引用」部分は送信されてこないので問題なくブロックされるはずです。
まあ、オリジナルのロジックで判定文字列数下限値を「150」とするのとどちらが良いのか、一概には決められません。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
|
http://www.xugj.org/modules/QandA/index.php?post_id=7966
こちらに
xmobileからの書き込み時には、protectorのpostcommon_post_need_multibyte.phpを無効にする方法を書いてみました。
長さん、こんにちは。
わざわざこちらまで、ありがとうございます。
XUGJのほうでGIJOEさんが指摘していますが、判定を「dirname」で行っているため、PCからでもxmobileアクセス可能な設定にしている場合に、このフィルターがスルーされてしまう危険性がありますね。
その点をきちんと押さえて(PCからはxmobileアクセス禁止)設定すれば、有効だと思います。 ありがとうございました。