PEAK XOOPS - News

パンくずリスト:Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%91%E3%83%B3%E3%81%8F%E3%81%9A%E3%83%AA%E3%82%B9%E3%83%88

今や、ある程度の深さを持ったサイトであれば、「パンくず」を実装することはほぼ必須と言えますが、XOOPSにはそれを統一的に扱う術がなく、サイトデザイナーが独自に実装するか、モジュールが独自に実装したものであきらめるかの2拓しかありませんでした。

というわけで、ここで xoops_breadcrumbs を提唱したいと思います。

各モジュールはxoops_breadcrumbsというテンプレート変数を$xoopsTplにアサインします。
その構造はこうなってます。

変数名: 'xoops_breadcrumbs'
型: 連想配列の配列（連想ではない）

一般的なパターン
[0] => array( 'name' => '(モジュール名)' , 'url' => '(モジュールトップの絶対URL)' ) ,
[1] => array( 'name' => '(トップカテゴリ名)' , 'url' => '(カテゴリ内一覧の絶対URL)' ) ,
[2] => array( 'name' => '(サブカテゴリ名)' , 'url' => '(サブカテゴリ内一覧の絶対URL)' ) ,
[3] => array( 'name' => '(コンテンツ名)' )

'name' のみで 'url' がないのも可。
ここでの重要な点として、'name'にはHTML表示用にエスケープされたものをアサインしてください。XC2.1の生値アサインの原則には反しますが、様々な理由から、ここに生値をアサインするのは難しいからです。

このような形ですべてのモジュールが、xoops_breadcrumbs をアサインすると、テーマ(theme.html)内に以下のように記述することができます。

<div id="theme_breadcrumbs">
	<a href="<{$xoops_url}>/">TOP</a>
	<{foreach from=$xoops_breadcrumbs item="item"}>
		&nbsp;>&nbsp;
		<{if $item.url}>
			<a href="<{$item.url}>"><{$item.name}></a>
		<{else}>
			<{$item.name}>
		<{/if}>
	<{/foreach}>
</div>

すっかり更新をさぼっていたProtectorですが、ようやくV3が形になりました。
メジャーバージョンが上がっていることからも判ると思いますが、今回は比較的大きな変更を伴っています。

一番大きいのが、XOOPS_TRUST_PATH側に本体を移したことです。このおかげで、セキュリティモジュールを冠しながら、公開側にロジックがデンと置いてある状況、.htaccessなどが効かなかったらPathDisclosureになるかもしれない、という不安から解消されました。

その代わり、mainfile.php に挿入する2行のinclude文が、ROOT_PATHからTRUST_PATHに変更されてます。2.57等からのアップグレードを行う場合、いったんmainfile.phpから削除して、モジュールアップデート後に挿入し直してください。

次に大きいのが、拒否IPの取り扱い変更です。今までは、XOOPS本体の拒否IP機能を利用していましたが、それだとどうしても復旧が大変です。レスキュー画面も使いやすくありませんでした。というわけで、単なるファイルに変更してます。もし自分自身が拒否されても、FTP等でそのファイルを消すだけです。（どのファイルかは、Protectorの管理画面に表示されていますので、事前にチェックしておいてください）

この変更のおかげで、拒否IPの判断にDBが不要となり、DoS系の攻撃にも比較的強くなったと思います。実際、DBコネクション発生の前に拒否できているので、かなり高速に処理が完了します。（もちろん、.htaccessの足下にも及びませんが）

あとは、ここで議論したXSS対策をいれてみました。BigUmbrellaのサブセット版です。副作用や速度的な影響がないように調整したため、POSTなどはノーチェックですが、それでもかなりマシになるとは思います。
http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=126

もう一つ、XUGJで思いついたグループ1だけのIP制限。結構、いけそうな気がしたので、採用してます。これまた１ファイルに記述されているだけなので、いきなりIPが変わって自分自身がログインできなくなっても、FTP等でそのファイルを消せば復活できます。

最後にSPAM対策。nao-ponさんの「URIの数をカウントする」という方法に感動し、さっそく取り込んでみました。Protectorでは、単純にURIの記述数、という相当にシンプルな形にしてます。このサイトではゲスト投稿を許可していないので効果の程はわかりませんが、運用してみた結果をお知らせいただければ幸いです。
元ネタ:
http://xoops.hypweb.net/wiki/5589.html

同じSPAM対策として、RBLフィルターや英語のみの投稿拒否、なんてプラグインも実装してたりします。

あ、そうそう。忘れちゃいけない。XOOPS Cube 2.1 Legacy RC での動作確認もしてます。
まったく問題なく動いているようです。

ずいぶんと出遅れてしまいましたが、picoを正式版にする前にやっておかなければ、と、Cube 2.1 Legacy RC での動作確認をしました。

ざっと調べた限りでは、私のモジュールで動作不良を起こすようなものは見つかりませんでした。

特に、インストール二段階目の一括インストールでも何もエラーを起こさないのにはほっとしました。（具体的には、ここで、d3forumやpico、wrapsをそれぞれ２つ以上、他altsysとpiCalを１つずつを一斉インストールしてもまったく問題なく動作した、ということ）

いくつか動作におかしいな、と思う点があったのですが、よく調べてみると、それらはすべて私のモジュール側のミスでした。モジュール互換性などで、コア側の問題はとりあえず見つかってません。これだけまったく別のコアなのに、高いモジュール互換性を保持しているのはスゴイとしか言いようがありません。

minahitoさん、nobunobuさん、Tom_G3Xさんの努力には感服するばかりです。

#それに比べて、同じレベルのコアをいじっているだけなのに、テンプレートの仕様を勝手に変更し互換性を失ってしまう本家版XOOPS2.0.14/15/16っていったい…

とりあえず、XC2.1 Ready! というアイコンも作ったので、これから動作確認がとれたものについては、このアイコンを付与していきたいと思います。

X2管理画面では、画面左のアイコンから操作を開始するわけですが、そのアイコンが多くなってくると目的のアイコンを探すのが大変になります。D3モジュールでは、各モジュールのdirname（modulesの下に置いたディレクトリの名前）をアイコン内に描画する、という方法で区別をつけていますが、ある程度以上増えてしまうと、それでも区別をつけるのは難しいでしょう。
実は、D3モジュールは、モジュールアイコンもモジュール個別にオーバーライドできるように作ってあります。やり方も、言語ファイルの個別オーバーライドとほぼ同じです。
公開側(XOOPS_ROOT_PATH/modules/dirname/) 内に、module_icon.pngという名前でPNG画像を置いてください。
たったそれだけで、dirnameのアイコンだけが差し替わります。
今後、モジュールが更新されても、基本的にはXOOPS_TRUST_PATH側のみなので、公開側にはノータッチですし、なんらかの理由で後から公開側を上書きする必要が出たとしても、少なくともその画像ファイルは上書きされません。
「色分け」「サイズ変更」などを駆使して、使いやすい管理画面になるといいですね。

#このネタ、どこかに書いたような気がしていたのですが、実はドキュメントにさえ書いていなかったことに気づいたので、2.1正式版がリリースされる前にあわてて上梓しました。
#というのも、これ、XC 2.1ではほとんど意味のない機能なんですよね〜

http://blog.solmetra.com/2007/01/19/php-vulnerability-possibly-affecting-spaw-1x-installations/
う〜ん…
このレポートを素直に読むと、古いPHPで register_globals=on だと、unset() した変数も後から有効になってしまう、ってことでしょうか？

それって、明らかにPHP本体の脆弱性であって、そんな可能性まで考慮しなきゃならないようでは、PHPのアプリケーションなんて何も作れなくなってしまうと思うのですが。

とりあえず、気持ちが悪いので common/spaw では、$spaw_imglib_include なんてまったく使っていないので、include部分も含めてコメントアウトしました。今の最新版のTinyDアーカイブに含まれてます。条件に該当してしまう、または気になる人はアップデートしてください。

common/spaw/dialogs/img_library.php

だけの上書きで十分です。

PHP自体の脆弱性はともかく、運用側としては、register_globals はoffでなければ事実上ダメですし、allow_url_fopen もoffにしておくべきでしょう。

ついでに書くと、やっぱりSPAWはその作りそのものに問題があります。あまりにもソースコードの見通しが悪すぎますから。

WYSIWYGエディターなら common/fckeditor をお勧めします。