PukiWiki in PHP, CGI and % encoding
Yasushi Shinjo
PukiWiki を、CGI で動かしたら、cmd=newpage のような URL を普
通のページの表示だと解釈しているようです。URL は、%の16進で
エンコードされて送られているようです。似たような問題にぶつかっ
て解決した人は居ませんか。
Apache のモジュールだと問題ないのですが、CGI だと問題になり
ます。狙いをつけてデコードすればいいんじゃないかと思うのです
が、PHP は、急には読めないですね。PukiWiki 自体、あんまりPHP
である必然性はないように見えました。HTML と PHP が混じってい
る所はないし。
PukiWiki 自体、CGI での実行はあんまり気合いが入っている感じ
がしません。CGI なら、Content-Type: text/html は必要ですよね。
その表示が出てないので、手で書き入れました。なんか違うような
気もしつつ。
------------------------------------------------------------
% diff pukiwiki.cgi.~1~ pukiwiki.cgi
0a1
> #!/usr/local/bin/php
121a123
> echo "Content-Type: text/html\n\n";
125c127
< ?>
\ No newline at end of file
---
> ?>
%
------------------------------------------------------------
あと、suExec の所の説明は、ちょっと怪しい気がします。
PukiWiki/CGI版PHPで動作させるには
http://www.pukiwiki.org/index.php?PukiWiki%2FCGI%E7%89%88PHP%E3%81%A7%E5%8B%95%E4%BD%9C%E3%81%95%E3%81%9B%E3%82%8B%E3%81%AB%E3%81%AF
suExec なら、pukiwiki.cgi は、suExec のチェックが入るので、
pukiwiki.cgi というファイルの uid, gid をきちんと設定する必
要があります。あと、そのプログラムから読み書きされるページの
データのファイルは、別にApache から読める必要はなくて、モー
ドもそのユーザから読み書きできれば、どうでもよいはずです。
705 とか 604 とか、グループが 0 になって、その他でまた出てく
るようなモードは、おかしいと思います。700 とか 600 でいいは
ずです。
PukiWiki は、1.4.3 を使っています。PHP は、モジュール版は、
HP 4.1.2 です。CGI 版は、PHP 4.3.1 です。
ブラウザは、関係ないと思いますが、Mozilla です。
PHP って、時々バグが出ているようなんですが、危ないのはどの辺
りでしょうか。ベンダーからのパッチは当てているので、表面的な
バージョンでは危なく見えても、一応大丈夫だと信じたい所なんで
すけれど。
続きは、PukiWiki でなくて、他の Wiki の方がいいという話でも
いいかと思います。
よろしくお願いします。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
YAMAGUCHI Takanori
<YAS.04Ap...@kirk.is.tsukuba.ac.jp>にて Yasushi Shinjo さん曰く，
>がしません。CGI なら、Content-Type: text/html は必要ですよね。
>その表示が出てないので、手で書き入れました。なんか違うような
>気もしつつ。
CGI ではなく、CLI 版としてビルドした PHP を使ってませんか？
ちゃんと CGI 版としてビルドした php では、Content-Type: を明示的に
出力しない場合は php.ini で指定した mimetype、charset で php 自身が
補うので不要です。むしろ、
>> echo "Content-Type: text/html\n\n";
のように echo を使うと、ヘッダではなくボディとして出力されてしまって
おかしなことになります。
Header("Content-Type: text/html");
とするのが正しいです。CLI 版では Content-Type の補完も Header() による
出力もされません。
% php -v
PHP 4.3.4 (cli) (built: Mar 23 2004 00:50:34)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
CGI 版ならば (cli) ではなく (cgi) となってるはずです。
Yasushi Shinjo
In article <0404101552...@mtj.biglobe.ne.jp>
YAMAGUCHI Takanori <yam...@mtj.biglobe.ne.jp> writes:
> pukiwiki を CGI で動かしたことはないので直接の疑問についてはわかりませんが、
> CGI ではなく、CLI 版としてビルドした PHP を使ってませんか？
はい。これが原因でした。今、PHP 4.3.5 をソースからコンパイル
して使ったら、PukiWiku が問題なく動きました。助かりました。
ありがとうございます。
------------------------------------------------------------
% /usr/local3/php-4.3.5/bin/php -v
PHP 4.3.5 (cgi) (built: Apr 10 2004 19:03:35)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend
Technologies
%
------------------------------------------------------------
コンパイル時のオプションは、こうです。
./configure --prefix=/usr/local3/php-4.3.5 --enable-discard-path
この --enable-discard-path ですが、次のページの「ケース 4:
Webツリーの外にPHPパーサを置く」という時に使うものだそうです。
http://jp2.php.net/manual/ja/security.cgi-bin.php
------------------------------------------------------------
ケース 4: Webツリーの外にPHPパーサを置く
非常に安全性の高いオプションとしてPHP パーサのバイナリをファイル 用
Web ツリーの外側、例えば /usr/local/binに置くことが考えられます。こ の
オプションの唯一の欠点は、PHP タグを有する全てのファイルの先頭 行に次
のような一行を加える必要があることです。
#!/usr/local/bin/php
また、ファイルを実行可能にしておく必要があります。この場合、実行 時に
シェルエスケープ機能 #! を使用する Perl や sh や他のスクリプト言語で書
かれた CGI スクリプトを処理するのと全 く同様に処理を行います。
この設定で PATH_INFO および PATH_TRANSLATED 情報を正しく処理するために
は、 PHP パーサを設定オプション --enable-discard-path を付けてコンパイ
ルする必要があります。
------------------------------------------------------------
「非常に安全性の高いオプション」と言ってますが、他の言語、た
とえば、Ruby とか Perl なら普通ですよね。インタプリタを GET
できる所に置いても、まあ別にバイナリが盗まれるだけで、それが
大問題という感じはしません。それが何で標準ではなくて、かつ、
それを discard-path と言うのかは疑問は残ります。
ところで、CLI って、どうやって使うのですか。
> のように echo を使うと、ヘッダではなくボディとして出力されてしまって
> おかしなことになります。
> Header("Content-Type: text/html");
> とするのが正しいです。CLI 版では Content-Type の補完も Header() による
> 出力もされません。
なるほど。補完というと、たとえば、PDF を生成したり、イメージ
を生成したりすると自動的に Content-Type を作ってくれるという
ことですか。それは、なかなか良さそうですね。
T.P.S.Nakagawa
新城＠筑波大学さんは
2004年04月10日(土)19時32分発信の
<YAS.04Ap...@kirk.is.tsukuba.ac.jp>すなわち
"Re: PukiWiki in PHP, CGI and % encoding" と題した記事にて
書かれました。
> > CGI ではなく、CLI 版としてビルドした PHP を使ってませんか？
>
> はい。これが原因でした。今、PHP 4.3.5 をソースからコンパイル
> して使ったら、PukiWiku が問題なく動きました。助かりました。
> ありがとうございます。
<>
> ところで、CLI って、どうやって使うのですか。
私の後輩の SE は (別に私の弟子ではない) プログラミング言語は
PHP しか知らないので、通常なら sed や awk , perl , ruby で行なわれる
ような処理も全部 PHP にやらせています。
そういうときには CLI 版は有効ですね。
========================================================================
「日本は、世界一の水族館大国です」
--
中川 恒雄 ( T.Nakagawa ) mailto:yae...@kikansha.jp
http://www.kikansha.jp/~yaemon/
Hiroshi Fujishima
> 続きは、PukiWiki でなくて、他の Wiki の方がいいという話でも
> いいかと思います。
Hiki は、Emacs から編集可能だそうです。
PukiWiki のいいところってどんなところですか。
--
Hiroshi Fujishima
Yasushi Shinjo
In article <86n05cq...@edge.first.tsukuba.ac.jp>
Hiroshi Fujishima <hir...@first.tsukuba.ac.jp> writes:
> > 続きは、PukiWiki でなくて、他の Wiki の方がいいという話でも
> > いいかと思います。
> Hiki は、Emacs から編集可能だそうです。
Hiki って始めて聞きました。Hiki のいい所は、Emacs から編集以
外何がありりますか。
> PukiWiki のいいところってどんなところですか。
去年は、Tiki を使っていたのですが、今年は PukiWiki かなあ、
という感じです。Tiki より PukiWiki がいいのは、こんな所です。
・添付ファイルを構造化して置ける。順序が変えられる。
・アクセス制御がある。（外部との連携がどのくらいできるか調査中。）
・ページの新規作成が簡単。
・導入が簡単。
こんな所でしょうか。PukiWiki の問題点、というわけでもないの
ですが、PHP で書いてあるので、手が出しにくいという所がありま
す。まあ、PHP を勉強しろという話ではあるのですけれど。
Tiki も、(Windows の) Emacs から修正できた気もしました。私は、
Unix のサーバに乗っているテキストファイルを直接 Emacs で修正
したりもしました。PukiWiki も別にバックアップの整合性の問題
が出てくるかもしれませんが、サーバにのっているファイルを修正
するのはアリなんじゃないですか。
Hiroshi Fujishima
> Hiki って始めて聞きました。Hiki のいい所は、Emacs から編集以
> 外何がありりますか。
tdiary の豊富な theme が使えます。
> こんな所でしょうか。PukiWiki の問題点、というわけでもないの
> ですが、PHP で書いてあるので、手が出しにくいという所がありま
> す。まあ、PHP を勉強しろという話ではあるのですけれど。
Hiki は ruby で書かれています。
> Tiki も、(Windows の) Emacs から修正できた気もしました。私は、
> Unix のサーバに乗っているテキストファイルを直接 Emacs で修正
> したりもしました。PukiWiki も別にバックアップの整合性の問題
> が出てくるかもしれませんが、サーバにのっているファイルを修正
> するのはアリなんじゃないですか。
web server が owner の file を編集する権限があればアリかもしれませんね。
--
Hiroshi Fujishima
Yasushi Shinjo
In article <86smesb...@edge.first.tsukuba.ac.jp>
Hiroshi Fujishima <hir...@first.tsukuba.ac.jp> writes:
> > Hiki って始めて聞きました。Hiki のいい所は、Emacs から編集以
> > 外何がありりますか。
> tdiary の豊富な theme が使えます。
見栄えは、私はあんまりこだわらないけれど、世の中一般的には、
大事でしょうね。
> Hiki は ruby で書かれています。
それは、いいですね。どこにあるんですか。
Tiki の機能でありがたかったのは、表の編集です。表を編集とす
ると、表の升目全部がtextarea か何かになって、一度に編集てき
ます。何に使うかというと、日程調整です。空き時間を探す時に、
埋まっている時間に名前を埋めていきます。そうすると、自然に空
いている時間が浮かび上がることになります。
PukiWiki とか Hiki とか、そういう機能はありますか？
Wiki 系でなくても、WWW でその手の表の編集ができるプログラム
がありましたら、教えてください。
> > Tiki も、(Windows の) Emacs から修正できた気もしました。
> web server が owner の file を編集する権限があればアリかもしれませんね。
あと、WebDAV 対応とか、ないですかね。クライアント側の問題も
あるかもしれないけれど。
Hiki の Emacs というのは、プロトコルは何なんですか？
Hiroshi Fujishima
>> Hiki は ruby で書かれています。
>
> それは、いいですね。どこにあるんですか。
http://www.namaraii.com/hiki/ にあります。
> Tiki の機能でありがたかったのは、表の編集です。表を編集とす
> ると、表の升目全部がtextarea か何かになって、一度に編集てき
> ます。何に使うかというと、日程調整です。空き時間を探す時に、
> 埋まっている時間に名前を埋めていきます。そうすると、自然に空
> いている時間が浮かび上がることになります。
[...]
> PukiWiki とか Hiki とか、そういう機能はありますか？
http://www.namaraii.com/hiki/?%28Hiki%29%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3
にありかもしれません。
> Wiki 系でなくても、WWW でその手の表の編集ができるプログラム
> がありましたら、教えてください。
http://www.gentei.org/~yuuji/software/uogashi/
http://www.gentei.org/~yuuji/software/after5/
>> > Tiki も、(Windows の) Emacs から修正できた気もしました。
>> web server が owner の file を編集する権限があればアリかもしれませんね。
>
> あと、WebDAV 対応とか、ないですかね。クライアント側の問題も
> あるかもしれないけれど。
>
> Hiki の Emacs というのは、プロトコルは何なんですか？
HTTP です。hiki-mode.el の他に、tdiary にふくまれている、http.el が必要
です。
http://yowaken.dip.jp/hiki/hiki.cgi?hiki-mode.el
http://kitaj.no-ip.com/rw-cgi.rb?cmd=view;name=tdiary-mode
--
Hiroshi Fujishima