ようやくというか今さらというか、d3pipesに更新Pingジョイントを追加しました。
あくまでジョイントですから、どのパイプのどの段階に挿入しても構いません。
SPAM Pingとして扱われないように、以下の2つのルールを適用してます。
- 前回から30分以内のPingは送信しない
- パイプ内を通っているデータが前回と違った時だけPingを送信する
当たり前ですが、そのパイプがゲストに公開されていないと、Pingに意味がありません。メインページだけでなく、RSSも許可することを忘れないでください。
それにしても、海外の有名どころなPingサーバはほとんどextended仕様なのに、国内はextendedってだけで拒否するサーバが多いんですね。extendedの方が、サーバ側の負荷も少ない気がしますが。
今年の6月頃から自動登録ボットが出回っているので、その対策をProtector用プラグインとして実装してみました。
最新版のProtectorで、filters_disabled に入っているpostcommon_register_insert_js_check.php を、filters_enabled にコピーすることで動作するようになります。
Protectorさえちゃんとインストールされていれば、コアHackは不要です。register.php へのアクセスだけに、透過的に働きます。
視覚障害者を排除するCaptchaは嫌いなので、JavaScriptによる対策です。こんなのでも十分に効くんじゃないかと見積もってます。(どうしても必要なら、このタイプのプラグインをCaptchaにするのもおそらく簡単です。もちろんコアHackなしで)
一応、XOOPS 2.0.16a-JP および XCL 2.1.1 にて動作確認を取っていますが、これを有効にした後でも、ちゃんとユーザ登録が機能するか確認してください。その際、JavaScriptを切ったらユーザ登録できないことも確認できれば最善です。
なお、Protectorの一般設定における「信頼できるIP」に含まれていると、このプラグインまで動作が回ってきません(つまり無条件でユーザ登録できる)。
ボット対策が生きていることを確認するためには、信頼できるIP以外で確認してください。
本家版XOOPSの2.0.14/15/16は、2.0.x というバージョンナンバーでありながら、互換性を大幅に失う形で機能拡張してしまった、困ったバージョンです。
正直言って、世界中の皆さんにも、XOOPS 2.0.16a-JPという安定版を使って欲しいところですが、なぜか日本以外では、圧倒的にXOOPS 2.0.16が利用されているようです。(不思議としか言い様がないのですが)
「どちらのコアチームにも与しない」と明言した以上、2.0.16もある程度サポートしないわけにはいかないでしょう。仕方ないので渋々、D3モジュール群の 2.0.16 対応をしてみました。
まず最初は、D3モジュールの土台となるaltsysです。0.55で、2.0.16における動作不良を一通り潰してみました。
あまりにも、テンプレートの仕様変更が酷いので、迷ったらコンパイルキャッシュを消す、という方針にしてます。
個々のD3モジュールについては、今後、徐々に対応していきます。
新しい本家コアチームが、このパッチを入れてくれるだけで、互換性も大幅に改善されて、コアチームもモジュール開発者もユーザも、すべてが幸せになるはずんですけどねえ。
本家も新しいコアチームを作ったのなら、まずはここから修正してくれませんかね。
0.32以降、d3pipesで、管理画面のAjaxを実装してみましたが、意外と知られていないのでここにも書きます。
キャプチャー画面を見れば判るように、「ドラッグ&ドロップによる並び替え」と「ジョイントタイプを選んだ時に自動的にオプションフォームが切り替わる」という2つの機能を実装してます。
これらは、common/lib と呼ばれるJavaScriptライブラリをXOOPS公開側にコピーして初めて機能します。
http://xoops.peak.ne.jp/md/mydownloads/singlefile.php?lid=104
ちなみに、この管理画面で使っているのは、BCOOLさんのbc_admin01です。
http://demo.2bcool.net/
altsysの管理画面テーマ機能用に最適化されたテーマで、とても使いやすいのが特長です。
なお、altsysの管理画面テーマ機能からいくつか不具合が見つかったので、出来ればaltsysもついでに最新版に上げておいてください。
http://larholm.com/2007/06/11/phpmailer-0day-remote-execution/
この件、恥ずかしながら、大垣さんのブログから知りました。(やはり大垣さんは素晴らしい!)
http://blog.ohgaki.net/index.php/yohgaki/2007/06/12/phpmailera_sa_a_sa_a_ca_sa_ca_sa_ma_ma_s
この穴を突けば、攻撃者がいきなりコマンドを実行できます。
XOOPSも、phpmailerを利用してますので、本来なら緊急の穴なのですが、実はデフォルトがphp mail() であるため、ここをあえてsendmailに変更した人だけが対象となります。
とにかく、一般設定->メール設定において、メール送信方法がsendmailとなっていないことを確認してください。通常、sendmailをコマンドとして利用できるなら、php mail()関数だって利用できるはずです。(よほど変な設定のホスティングサービスでもなければ)
とりあえず、Protector-3.04 では、このチェックも入れてみました。
メール設定がsendmailだったら、「いますぐ変更して!」という旨のアラートを出します。
検索でヒットするように、Protectorが出力するアラートメッセージを貼り付けておきます。
"phpmailer security hole! Change the preferences of mail from "sendmail" to another, or upgrade the core right now!"