Flash Player 9 beta for linux
2006/11/20付けでBeta版のバージョンアップ行われたようです。IA64は出さないのかな?出してほしい。
2006/11/20付けでBeta版のバージョンアップ行われたようです。IA64は出さないのかな?出してほしい。
何故かmb_send_mailでメールが文字化けする、普通に運用しているサーバでは問題が無いにも関わらず…
調べてみるとmbstring.languageのaccess設定が6になっていました。6つまりスクリプトからは変更できない状態になっています。運用サーバ環境(開発環境含む)ではphp.ini設定はほとんど全て仮想サーバレベルで設定していたので今まで気が付きませんでした。
mbstring.languageの設定が変更できないと、mb_send_mail()を使って正しくメールを送信することができなくなります。(日本だけ、とかなら良いですが)この件、かなり「怒」なので時間ができたら誰が変更したか調べる事にします。
PHPは5.1…
追記:
mb_send_mail()で文字化けで困っている方は、php.iniなら
mbstring.language = “japanese”
Apacheの設定ファイル、.htaccessなどなら
php_value mbstring.languge japanese
と設定します。これで日本語メールでも文字化けしなくなります。デフォルトのmbstring.language設定(neutral)の場合、日本語メールは正しく送信できません。
パッチをするなら(PHP_5_2ブランチ)
cvs diff: Diffing ext/mbstring
Index: ext/mbstring/mbstring.c
===================================================================
RCS file: /repository/php-src/ext/mbstring/mbstring.c,v
retrieving revision 1.224.2.23
diff -u -r1.224.2.23 mbstring.c
— ext/mbstring/mbstring.c 11 May 2006 14:47:34 -0000 1.224.2.23
+++ ext/mbstring/mbstring.c 10 Nov 2006 05:10:51 -0000
@@ -739,7 +739,7 @@/* {{{ php.ini directive registration */
PHP_INI_BEGIN()
– PHP_INI_ENTRY(“mbstring.language”, “neutral”, PHP_INI_SYSTEM | PHP_INI_PERDIR, OnUpdate_mbstring_language)
+ PHP_INI_ENTRY(“mbstring.language”, “neutral”, PHP_INI_ALL, OnUpdate_mbstring_language)
PHP_INI_ENTRY(“mbstring.detect_order”, NULL, PHP_INI_ALL, OnUpdate_mbstring_detect_order)
PHP_INI_ENTRY(“mbstring.http_input”, “pass”, PHP_INI_ALL, OnUpdate_mbstring_http_input)
PHP_INI_ENTRY(“mbstring.http_output”, “pass”, PHP_INI_ALL, OnUpdate_mbstring_http_output)
1行パッチなので他のバージョンでも同じ場所を直せばOKです。パッチをすればmb_language()で言語設定を変更しmb_send_mail()で正しくメールが送信できるようになります。
PHP 5.2.0のsetcookie/setrawcookie関数からhttpOnly属性をクッキーにつける事ができるようになりました。httpOnly属性はMicrosoftが独自に拡張した仕様で、JavaScriptからクッキーの値を使用できなくする機能です。httpsでのみクッキーを送信するsecure属性に似ています。
Microsoftの独自拡張なのでIEでは利用できましたがFirefoxでは利用できません。しかし、アドオンを使用することでhttpOnly属性をFirefoxでも利用できるようです。
httpOnly
by Stefan EsserAdds httpOnly cookie support to Firefox by encrypting cookies marked as httpOnly on the browser side, so that JavaScript cannot read them.
Hardened PHP ProjectのSfefanさんが作者です。
XSSで自分のセッションを盗まれるリスクが低減できるのでお勧めのアドオンだと思います。
PHP 5.2.0がリリースされていますが少なくとも2つ重要なセキュリティフィックスがあります。5.1/4.4ユーザが5.2.0にアップグレードするには時間が必要と思うのでWikiどのパッチが必要か書いておきました。PHP4はこちらです。
PHP4.4にはありませんがPHP5.1にはecalloc(メモリ確保関数)に整数オーバーフロー脆弱性があります。この脆弱性は随分前にPHP4で修正されたバグですがPHP5ブランチにマージされ忘れていた、という代物です。最も簡単に攻撃可能なケースはserializeされたPHP変数をフォームやURLに埋め込みそれをunserializeで処理しているケースです。
htmlspecialchars()/htmlentities()のヒープオーバーフローのPoCは見かけていませんがパッチを見ればどのような入力でオーバーフローするのか見る人が見れば直ぐ分かると思います。
リンクをクリックするとデモが見れます。久しぶりにZendFrameworkのホームページを見てこのデモがある事に気が付きました。
IBMの方がZendFrameworkを利用して作っているらしいです。AJAXはもちろんですが、Wikiコマンドと言うシンプルな言語でいろいろ拡張できるようになっている様です。ドラッグアンドドロップで設定するGoogleマップと天気予報の連携のデモがあります。UIのほとんどはDojoを使っているのだと思われます。(ソースか実物を見ないと分かりませんが)
確かに便利そうにも見えますがWikiコマンドには括弧が多すぎな気もします。Lisp好きな方がデザインしたのかも知れませんね。
PostgreSQL 8.2のリリースノートは非常に長いのですがアプリケーションプログラマのコーディングスタイルに大きく影響するのは次の変更(追加)だと思います。
Add INSERT/UPDATE/DELETE RETURNING (Jonah Harris, Tom)
This allows these commands to return values, such as the computed serial key for a new row. In the UPDATE case, values from the updated version of the row are returned.
MySQL等で挿入後のID番号が取得できる機能がPostgreSQLでも作れるようになりました。
create table test (
id serial,
msg text,primary(id)
)
としてidフィールドの値が何になったのか分からないと困る場合が多かったので
create table test (
id int8,
msg text,primary(id)
)
としてsequenceの次の値を取得してidにセットしていたと思います。今後はより気軽に
INSERT INTO test(msg) VALUES (‘abc’) RETURNING *;
として挿入後のデータが参照できるようです。
Ruleやストアドプロシージャでデータを加工している場合にも便利ですね。
PostgreSQLの場合、6.xのころからRuleを使うと比較的簡単に全ての変更をログできるのですが、この機能を使えばアプリケーション側でデータのログを取るコードが簡略化できます。データベースレベルではアプリケーションを操作しているユーザIDが分からない場合が多いので便利になります。
PostgreSQL 8.0は2005年1月にリリースされました。SAVEPOINTは8.0からサポートされている機能ですが、2006年4月の記事で「サポートしていない」と間違った情報が記載されているページを見つけました。
ロールバックはトランザクションの開始処理まで戻るのが基本であるが,「セーブポイント」機能を利用すれば部分的な処理の取り消しが可能になる。図4[拡大表示]上に示したようにトランザクションの中に「SAVEPOINT(セーブポイント名)」を設定し,「ROLLBACK TO(セーブポイント名)」とすれば,ROLLBACKからSAVEPOINT間の処理を取り消すことができる。1つのトランザクションには複数のセーブポイントが設定可能である。セーブポイント機能はOracleにはあるがPostgreSQLには無い
しかし、よく見ると
出典:日経オープンシステム 2003年2月号 142ページより
(記事は執筆時の情報に基づいており,現在では異なる場合があります)
とあり書いた時点では正しい情報です。3年も経つとかなり変わりますから技術記事の再利用は難しいですね。この記事は新人対象のようですがこれを読むとそのまま信じてしまいそうです。
本書はPHPプログラミング「入門」と銘打っている。しかし、たとえば値渡し・参照渡しといった重要事項が、ごく簡単にしか説明されていない。これでは、全くのプログラミングの素人にはきついのではないか。逆に、CやPerlなどをかじったことがある人であれば、簡潔でいいのかもしれないが…。
また、具体的な関数・メソッドの索引はほとんど省かれている。だから、実際にプログラムを書くためには、他のマニュアルで確認する必要がある。とはいえ、公式サイトのマニュアルが日本語版も充実しているからそれを読めばいいのだが、巻末の索引だけで事足りないのは不満。
技術書には
– チュートリアル
– リファレンス
– 解説書
の3種類があると考えています。私としては「入門書 != チュートリアル」「入門書 != リファレンス」であり基本的には「入門書 == 解説書」だと思っています。
もちろん手取り足取りのチュートリアル型の入門書を否定するつもりはありません。チュートリアルが必要・好みの方はそのタイプの入門書を購入されれば良いと思います。執筆時点でチュートリアル型のPHP入門書は多数出版されていたので多少硬派なPHP入門書(解説書)として書いてみようと思って執筆しています。このコメントにあるように既にプログラミングを知っている方に読みやすい、分かりやすいを狙っていたのも確かです。
参照渡しと値渡しの解説が初心者には不十分とあります。自分でもどう書いたのか忘れたので後で見てみることにします。リファレンスとして利用できるようになっていた方が便利なのは分かります。この点は考慮した方がよさそうです。
書名に「はじめて」と書いてあるのでプログラミング初心者向けのチュートリアル型の入門書でないと「期待と違う」と言うことになってしまうのでしょうね… この本の「はじめて」ははじめて言語としてPHPを解説した本、という意味をこめて付いているのですが誤解を招いてるのでしょう。書名は大切ですね。
あとAmazonの評価を見ると「減点方式」で評価している方が多いようです。とりあえず「満遍なく」が良いようです。「はじめてのPHP言語プログラミング」のコメントはどれも非常に参考になりました。これから執筆予定のZend Framework+Prototypeの入門書の執筆の参考にさせて頂くつもりです。
「Webアプリセキュリティ対策入門」には評価が付いていないです。このブログでもAmazonでも構わないのでご意見を頂ければ参考にさせて頂きます。
McAfeeのインターネットセキュリティスイート2006を使ってみました。この製品はマイクロソフトのみ環境でのみの利用を想定しているのか、デフォルトブラウザがFirefoxだとインストール後のダウンロードで問題が発生しました。プライバシーを保護するプログラムが中途半端な状態になり、削除もアンインストールもできない状態になりました。
# しかもこのプライバシー保護用のプログラムは重すぎです。
# 結局重すぎで使えないプログラムなのでインストールしてい
# ません。あまりにCPUを使うので最初はマルウェアのプロセス
# かと思いました。
更新用のプログラムがIE6を使うようになっているのでIEがデフォルトでなければならないようです。私のLinux/WindowsのFF1.5ではサポートページのレイアウトが崩れているのでデフォルトブラウザがIE以外に設定されているのは想定外??
更新用プログラムを今時わざわざIEのActiveXとして動作させるプログラムにしてくても…と思います。しかも「セキュリティで保護されていないコンテンツ含まれています」と毎回表示される画面もあります。
とにかく困ったのはFFがデフォルトブラウザだったせい(?)で中途半端にインストールされたので、インストールも再インストールもアンインストールできなくなったことです。マカフィーのサイトにテクニカルサポートのFAQがあるのですが、インターネットセキュリティスイート2006のインストール・アンインストールは
http://www.mcafee.com/Japan/mcafee/faq/ssi_answerCSAllProducts.asp?ancQno=AP-00003&ancProd=AllProducts&ancExQNo=IS-00003&ancExProd=InternetSecurity&ancExVersion=:6%20:2005%20:2006
だけのようでした。当然ですがこのページ書いてあるようなことは既にやっています。全く役に立ちません。散々苦労してやっと
マカフィー製品を完全に削除するツール
http://www.mcafee.com/Japan/mcafee/faq/howtodownload.asp
を見つけコレで全部削除できました。一旦動作すると予告なしに勝手に再起動するので注意が必要です。再起動後にログインすると自動的に削除を再開します。セーフモードで実行すると再起動無しに全て削除できるようです。
このページの日付は2004年と日付が古いですがインターネットスイート2006でも使えるようです。きっとインターネットスイート2006ではサポート対象外なのでしょうけどFAQの分かりやすい場所に載せておいてほしいですね。マカフィー製品で困ったことになった方は上記の削除ツールを試してみると良いと思います。
このブログでZend Frameworkの事はほとんど書いていませんが、セキュリティ関係のところを少しだけ書きます。
Zend Frameworkはまだまだ作りかけ、と開発元が言っているだけあって、セキュリティに関係する部分も作りかけだったりします。
例えば、mysqliアダプタは適切にエスケープ処理されていますが、Oracleアダプタのエスケープ処理は全く行われていません。DB2のアダプタの場合、”でくくられるべき所がくくられていなかったりします。
Zend Frameworkとは関係ありませんが、PostgreSQLのPDOドライバは出来が悪いので事実上PostgreSQLでZend_Dbは使えません。
# 一見使えるように見えますがメモリ管理に問題がある
# らしく、はまる可能性があります。
PHPカンファレンスで「Zend Frameworkを使っている方?」と聞かれて、手を上げたのは私の他数名だったので大丈夫とは思いますが、実際のシステムに使うにはコードをよく読んでから使わないと思わない落とし穴にはまる事になります。
秋の1.0リリースかリリース候補では修正されていると思いますが、今のところこんな感じです。
PostgreSQLのプリペアードクエリを使ったプログラムのユニットテストを書いてユニットテストの書き方の問題に気がつきました。普通にユニットテストを書くと
relation with OID ##### does not exist
というPL/PgSQLで良く見かけるエラーが発生してしまう場合があります。
通常ユニットテストを書く場合、テストのセットアップ関数(メソッド)で
create table test (a text, i int);
テスト終了時に
drop table test;
と書きます。
プリペアードクエリの場合、コンパイルされたSQL文がバックエンドにキャッシュされるので「Web環境などで永続的な接続」を行っている環境でこの様な初期化、終了ルーチンを持つユニットテストでPostgreSQLのプリペアードクエリを実行するテストを「2回以上」行うと
relation with OID ##### does not exist
とエラーが表示されてしまいます。キャッシュされた(プリペアされた)SQL文に対応するテーブルが削除されてしまった後もクエリはキャッシュされているので削除されたの存在しないテーブルアクセスしようとしているので上記のエラーがでます。
# プリペアされたクエリは名前でなくOIDでテーブルにアクセスするので
# このエラーが発生します。
コマンドラインからのユニットテストの場合、接続の種類は影響しませんがPHPでWebサーバ上でユニットテストを実行する場合、pg_prepare, pg_execute を使ったプログラムのユニットテストにはpg_connectを使うほうが良いです。pg_connectを使っていても同じ接続を使っている間にテーブルの削除/作成を行ってもpg_pconnectを使っている場合と同じ理由でこのエラーが発生します。コマンドラインでもすべてのテストを実行するスクリプトを利用している場合は注意が必要だと思います。PL/PgSQLのエラーが何故発生するのか理解していれば直ぐに原因に気が付くと思いますが、そうでなければなかなか気が付かないかもしれません。
私も最初は何の事だか解らずググってもPL/PgSQLのエラーに関連するページが表示されていました。pg_prepare/pg_executeについては少なくとも上位には表示されなかったので書いておきます。
PostgreSQLのプリペアードクエリの実装(と言うか実際にOID参照しているもの)を詳しく調べてから書いていないので「実装と違う」という場合は是非指摘してください。
# Javaのユニットテストでこの問題が発生する、というページ
# も無かったような気がします。当り前すぎ(FAQ)だから?
# 問題を回避するもう別の方法にDEALLOCATEを使ってプリペアされた
# SQL文を削除しておく方法もあります。削除するのは面倒ですがこちら
# の方法ならどのような環境でも困らないと思います。
タイトルどおり「書かない日記」なっているので久しぶりに書きます。
先日のPHPカンファレンスで私のセッションを聞かれた方は「一応、問題はレポートしてあります」と話していた件、と言えば覚えていらっしゃると思います。この件、返信メールが来ていました。他のシングルバイト圏の方と話したときと同じかなと思いました。「これって問題なの?」と言う内容のメールでした。とりあえず「コミットしておいてください」と返信しておきましたがどうなることやら… 日本の開発者でも最初は「??」と思われる方も多いので仕方無いのでしょう。
PHPカンファレンスの私のセッションのプレゼンテーションファイルをご希望の方、メールをください。このプレゼンテーションファイルは個人的に使うか出所が分からないように一部のみ使って頂けるようお願いします。
10日ほど忙しくてブログ更新とスパム削除をサボっていると、SPAMが2500以上もたまっていました.. 本格的に対応しないと….
ohgaki.netのメールサーバにはqmailを使っているのですが、 また”unable to scan $HOME/Maildir”とpop3d がエラーで終了してしまいました。
このエラーはエラーメッセージの通りMaildirをスキャンできないため表示されるエラーです。qmailのpop3dがMaildirをスキャンしている途中に何らかのエラーでスキャンに失敗した場合に表示されます。私が知る限りでは2種類の原因があります。
1. Maildirへのディレクトリへのアクセス権限の問題。(ユーザがMaildirを所有していないなど。Virtualホストの場合はVirtualホスト管理アカウント以外の所有になっているなど)
2. pop3dのrunスクリプトでsoftlimit(利用可能なメモリを制限するコマンド)を利用しているとpop3dがその制限を越えてメモリを利用しようとした場合。
今回の場合、普通に使えていたpop3dが突然特定のアカウントだけで利用できなくなったので2のケースかな?と思い10MB余分にメモリを使えるようにしたらエラーが無くなりました。前に同じ原因でエラーが起きたのを覚えていたので良かったのですが、次は忘れているかもしれないのでメモとしてブログに残しておきます。
ディスカッションを行うMLを除き「MLのTo:(宛先)に送信先のユーザメールアドレス(各個人のメールアドレス)を記載するのは迷惑だ」と思っていました。理由は次の通りです。
– MLの情報は私信ではない。したがってTo:である必要はない。
– To: に自分のメールアドレスが入っている場合には特別なフィルタ処理行っているユーザが多いと思われる。
商用サイトのMLなどはTo:に設定されている特別なフィルタ処理を考慮して、ユーザがメールを読んでくれやすいよう「確信犯」でTo:に送信先メールアドレスを記載していると思います。
確かに昔はTo:に送信先に個人のメールアドレスアドレスを使っていると読まれる確立が高くなり、商用MLの送信者にはある程度のメリットがあったと思います。しかし、最近はSPAMが多くなりすぎていてデメリットの方が多いのではないかと思います。
例えば、私の場合フィルタルールでTo:かCc:に自分のメールアドレスが記載されている場合、特別なフォルダに保存されて分かるように分類しています。しかし、詐欺・迷惑メールは一部の商用MLと同じくTo:に自分のメールアドレスを記載して送信してきます。MLのメールも詐欺・迷惑メールも送信先のユーザに読んでほしいので同じ事をしてきます。その結果、私の個人アドレス宛のメールフォルダには詐欺・迷惑メールと振り分け処理を行っていないMLのメールが保存されます。
詐欺・迷惑メールの多くはSPAMフィルタでほとんど削除されますが、量が多すぎて一部はフォルダに残ってしまいます。MLのメールも残っているのですが、MLのタイトルと迷惑メールのタイトルはたいして違いが無い場合も多いので間違ってMLのメールをSPAMメールとマークしてしまう場合があります。(AmazonのメールとかSPAMになっていてキャンペーンのクーポンメールがゴミ箱に行きかけたことも…)一旦、迷惑メールと判定してしまうとかなりの確立で同じMLからのメッセージは迷惑メールとして処理されてしまう事になります。これでは、「ユーザに読んでほしいからTo:にユーザの個人メールアドレスを設定する」意味が無いと思います。
確かに私信に近いカスタマイズされたML(というよりはダイレクトEメール)も多いですが、customers@example.comの様なアドレスを使い、タイトルのプレフィックスにサイト名を書いて「example.com: あなたにお勧めの10冊!」等と書いた方がスパムに分類される確率が低くなると思います。特にユーザが「迷惑だ」と思っていない場合には効果が高いと思います。
まっとうなMLは宛先にユーザのメールアドレスを使用しない方が良いように思います。
システムが自動的に送信するメールでも一部のメールにはTo:にcustomers@example.comのようなアドレスは向かない物もあると思いますが、多くの商用MLはTo:に個人メールアドレスを設定する必要は無いように思えます。