cles::blog

PHPをリコンパイルしようとしたらなぜかundefined reference to `libiconv_open' というエラーでmakeが通らなくなってしまって困ったので、いろいろ調べてみたら下記のような情報がありました。

あ～ゆ～どりま～ | さむーい。

なんかiconv周りでエラー。configureの時にでも問題あるのかな？と思いつつ、configureのいじり方はよくわからないので以下のmake方法で解決。

make clean make ZEND_EXTRA_LIBS='-liconv'

多分、iconvをソースからインストールしたせいだろうなぁとは思いますが、とりあえず上記の方法で解決はできました。
忘れないようにメモしておきます。

Ajaxを利用したサーバーインストール型のオープンソースなWebメーラーとしてはRound Cubeが有名ですが、いつの間にか@MailにAtMail Openというオープンソース版ができていたので導入してみました。

AtMail Open: PHP Webmail client - Redefining Open Source Webmail

AtMail is an open source webmail client written in PHP. We aim to provide a elegant Ajax webmail client for existing IMAP mailservers, with less bloat and a focus on an intuitive, simple user interface.

IMAPサーバや、MySQL、PHPを使うことができるWebサーバが揃っているのであれば、インストール自体はインストーラーに従うだけなので１０分もかからないで導入することができます。インタフェイスは英語ですが、日本語の扱いも特に問題ないようです。ただ、POPサーバには対応していなかったりと上位版の機能限定版という面は否めません。本格的に使うのであれば有料版もしくは他のプロダクトを検討するのが良さそうです。

去年からアナウンスされていた通り、PHP 4.xのメンテナンスは今日まで。
ということで、最後のリリース PHP4.4.9 がリリースされています。

PHP 4.4.9 released!

The PHP development team would like to announce the immediate availability of PHP 4.4.9. It continues to improve the security and the stability of the 4.4 branch and all users are strongly encouraged to upgrade to it as soon as possible. This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last PHP 4.4 release.

うちはもう5.2.系に移行完了していますが、まだ4.4.xを使っている場合にはそろそろ移行を考えたほうが良いかも知れませんね。PHP 5.3.xのアルファ版のリリースも始まっているようなので、アプリが大規模でかなり修正工数がかかる場合はこちらに照準を合わせるのもいいのかもしれません。

DoCoMoのCSS仕様はインラインのみに対応なので、テンプレートにスタイルがハードコーディングになってしまったりして困っていたんですが、外部CSSを読み込んでインラインに展開してくれるPHPライブラリが公開されていました。

DoCoMo向けにCSS指定をインラインに埋め込むPHPライブラリ「toInlineCSSDoCoMo」作りました : アシアルブログ

とくにDoCoMoのCSS(i-CSS)は開発者泣かせですね。インラインのみに対応とか、開発しにくくて涙ちょちょぎれそうです。

さてさてそんなDoCoMoのCSSですが、PerlにはHTML::DoCoMoCSSというCPANライブラリがあります。styleタグで指定した外部CSSファイルを読み込んで、インラインのstyle要素に入れ込んでくれるというすぐれものです。
(中略)
PerlなんてわかんないよPHPじゃないと使えないよ(･ω･`)ｼｮﾎﾞｰﾝって思ったので、これをPHPで作ってみました。

PerlのHTML::DoCoMoCSSをPHPに移植したもののようで、Windowsの最大の発明はゴミ箱の標準装備という冒頭部分以外は秀逸です。ちょっと使ってみましたが、開発は大分楽にできるようになりそうです。

Perlはこの手のライブラリが非常に多いので、確かにPHPから見ると羨ましい限りです。この調子でMechanizeとか移植してくれる人がいないかなと期待してたりするんですが、難しいですよね。。。。。

先日、しづきさんにプラグインをE_STRICTで実行するとエラーが出るという話を聞いた気がするので、E_STRICTにするとどんなエラーが出るのか調べていたら、E_STRICTにすると出現するエラーのまとめサイトを見つけたのでメモ。そういえば、もう少しでPHP 4.x系のメンテナンスが完全に停止されますね。

PHP E_STRICTで表示されるエラーメッセージを調べてみた | Shin x blog

PHP5で推奨されていないスクリプトをチェックするのがE_STRICTです。E_STRICTが有効なのは分かっていたのですが、実際にどんなスクリプトがE_STRICTに引っかかるのかが、あやふやでした。

そこでE_STRICTで出力されるメッセージをPHPのソースから抜き出してみました。どのようなスクリプトがE_STRICTに引っかかるのか（引っかからないか）のヒントになればと思います。

これを読んでNucleus関連に当てはまりそうなところを考えてみると、参照の取り扱い関連の2. Assigning the return value of new by reference is deprecatedとか、8. Only variables should be assigned by referenceあたりが膨大に出そうな気がします。対応としては、ソースコード中から =& を取り除くことになるのだと思いますが、本当に副作用がないのかどうかを検証するのは骨が折れそうです。

fjskさんからうまく動かないという話をもらったので調べてみたのですが、CryptUtil.phpが乱数を/dev/urandomから取得しているので、サーバー環境がWindowsだったり、open_basedirなどによって読み取りが制限されていると、下記のようなエラーが発生して実行が停止します。

Fatal error: Define Auth_OpenID_RAND_SOURCE as null to continue with an insecure random number generator. in /path/to/sharedlibs/Auth/OpenID/CryptUtil.php on line 52

このあたりの仕様は不便ですが、セキュリティにかかわることなので自動的にfallbackしないようになってるみたいです。fallbackさせるにはAuth_OpenID_RAND_SOURCEをnullで定義してあげればよいみたいです。

こんな感じで対応してみることにしました。

phpにはデフォルトではあまり望ましくない動作をする部分が少なからずあります。
そんな部分をphpのセキュリティ界隈では有名な大垣さんがまとめたメモを見つけました。

PHP/脆弱性リスト/メモ - yohgaki

「修正できない（されない）脆弱性」「修正されていない脆弱性」プログラムの脆弱性原因などを記載したページです。ベストプラクティス的な項目も含めています。これらの仕様自体が問題とは言えないまでもセキュリティ上の問題の原因(アタックベクタの一部)となり得る仕様はプログラマと知っておくべきなので掲載しています。

phpでプログラムをする時には一読しておくといいと思います。
また、一部はphp.iniのデフォルト設定に起因する問題だったりするので、php.iniが編集できる場合には見直しておくといいと思います。

CACHEMANAGER.phpの開発にあたって、Cache_Liteの代わりに使えるようなファイルベースのDBが欲しいと思っています。それだけの用途であればSQLiteのようにSQLを解釈できる必要が全くないので、qdbmみたいなもので十分なんですが、これらはどちらもPHPのコンパイル時に指定が必要となるので、Cache_Liteのようにみんなが使えるというわけにはいきません。

そんなわけで、Pure PHPなDBがないかと思って探してみました。見つかったのはGladius DBとtxtSQLという２つのプロダクトで、どちらもPHPのオブジェクトをシリアライズしてファイルに格納するようになっていました。

とりあえずこのサイト自体はPHP5に移行が完了しました。これはNucleusが元々PHP5対応していたので苦労がなかっただけなのですが、仕事で使っているサーバの移行は頭が痛いところです。

企業ユーザはPHP4からPHP5への移行は慎重にすべき

しかし、新規開発を除き、企業ユーザには今すぐPHP5へ移行すべきだ、と一概にアドバイスできません。3つのお薦めしない理由があります。
* PHP4からPHP5へのマイグレーションはそれほど簡単ではない
* PHP5に移行するとマイナーバージョンアップに追随しないとならない
* PHP5.3のリリースが準備されている

大垣さんのこのエントリを読む限りでは、PHP5.3へのマイグレーションはPHP4->PHP5.2並みに大変なようなので、さすがにこのあたりは頭が痛いかも。誰かに担当を代わってもらうまでこのまま引っ張って、その人にやってもらうなんていう作戦を取りたくなったり。。。。。

今回のNP_OpenIdではJanRain PHP OpenIDというライブラリを使いましたが^*1、思わぬところで何箇所かはまったのでメモをしておきます。

• ^*1: その他のOpenIdについてはhttp://wiki.openid.net/Librariesにまとまっています。