Home > アーカイブ > 2013-05

2013-05

勉強会では、たった一つで良いのでアクションを

この記事の所要時間: 38

勉強会に参加したらたった一つで良いので、アクションを起こして帰りましょう。

5588314548_43402db731
Photo by omoon.

このエントリは PHP カンファレンス関西2013リレーブログです。
前日は @omoon さんの「PHPカンファレンス関西2013に来てドラ娘に会おう」でした。毎年異様な盛り上がりを見せるドラ娘の登場ですが、今年も期待して下さい:D

勉強会やカンファレンスに参加すること自体がアクションではあるのですが、ただ聞いて帰るのはもったいない。

セッション聞いて、高揚した気分も、週明けの日常に入ると一週間もしないうちに収まってしまいます。せっかく受けた刺激をより刻みこむためにも何かアクションを起こして帰りましょう。

では、どんなアクションを起こすのが良いか。

質問する

セッションの終わりには質疑応答の時間があります。そこで手を挙げて、セッションの内容で気になった点を聞いてみます。わりと勇気がいることですが、スピーカーに直接疑問を投げかけられる良い機会です。

「こんな初歩的なこと聞いても大丈夫?みんな実分かっていて、自分だけ知らないのでは。。。」と思って、質問を躊躇していませんか?そういった疑問はたいてい隣の人も疑問に思っていたりするものです。

またスピーカーとしても質問があるのは嬉しいものです。セッションの内容が届いたから質問が出るわけです。スピーカーへお礼を言う意味でも質問をしてみて下さい。

話してみる

セッションで偶然隣に座った人にセッションの内容などについて話してみる、というのが出来れば良いですが、さすがにこれはハードル高そうです。そこで話しやすような人を探してみましょう。

スピーカー。良いですね。セッションが終わった後なら、解放感もあって気軽にお話してくれると思います。
スタッフ。運営でバタバタしてるかもしれませんが、大丈夫です。

でも一番話しやすい人は誰でしょう?それはブースの人です。ブースは参加者の方に足を止めてもらってこそなので、来てもらってお話をすることを心待ちにしています。いっちょ話して見ようという方はぜひブースへ行ってみて下さい。

懇親会に参加するのも一つのアクションですね。懇親会では人と話すハードルがグッと下がります。一日を一緒に過ごした者同士、楽しみましょう。

PHPカンファレンス関西2013 懇親会申込

発表する

発表すれば、セッションを聞くだけとは比べものにならない刺激を受けます。発表がうまくできても、うまくできなくても確実に記憶に残ります。当日に発表内容を考える強者もいますが、事前に準備をしておけば、イベントへ参加する気持ちも高まりますし、何より「自分のイベント」という感情が芽生えます。

まずは LT をやってみるのはどうでしょう。

LTはちょっと長い自己紹介のようなものです。自分が興味あること、調べたこと、面白いと思っていることを 5 分間聞いてもらう時間です。一緒にイベントに行く人がいない、知り合いがいない、という人こそ LT しておけば、後の懇親会では話しかけられること請け合いです:D

ちなみに PHP カンファレンス関西2013 では、まだ LT 募集中です!いっちょやってみよう、という方はぜひどうぞ。

PHPカンファレンス関西2013 LT 申込

前のめりで

受け身ではなく、一歩前に出てアクションを起こすと勉強会やカンファレンスはもっと楽しいものになります。参加したからにはぜひ何かアクションを起こしてみましょう。

明日のPHP カンファレンス関西2013リレーブログは、 @msng さんです。よろしく!

  • コメント (Close): 0
  • トラックバック (Close): 0

CakePHP 1.2.x, 1.3.x, 2.x の Paginate / PaginatorComponent に SQL インジェクション可能な脆弱性

この記事の所要時間: 353

CakePHP(1.2.x 以降全て)の Paginate / PaginatorComponent にて SQL インジェクション可能な脆弱性が見つかりました。

cake-logo

すでに cakephper さんの blog でも注意勧告されていますが、 連休中にリリースされた情報ということで見落としている人もいると思うので、こちらでも。

内容

この脆弱性を悪用すると Paginate / PaginatorComponent にて SQL インジェクションが可能となります。
現在は影響の大きさを考慮して、公式サイトでは脆弱性の詳細は明らかにされていませんが(一定期間、ユーザのアップグレードを待って公開するようです。)、私が開発環境で試したところ、SQL インジェクション可能であることが確認できました。

対象

Paginate / PaginatorComponent を利用している全ての CakePHP アプリケーションが対象となります。
Paginate / PaginatorComponent を利用していない場合は、本脆弱性は存在しませんが、今後利用する可能性も考慮して、可能であれば対応しておいた方が良いです。

簡易的ですが、Paginate / PaginatorComponent を利用しているか否かは以下のコマンドで調べることができます。1 件でも該当行があれば、Paginate / PaginatorComponent を利用している可能性があるので、下記対応を検討して下さい。

$ cd /path/to/cake
$ find ./app -type f -name "*.php" | xargs grep -i paginat

対応方法

下記のいずれかの方法で対応を行なって下さい。b. についてはフレームワークを理解している必要がありますので、内容が理解できないようであれば a. の方法をおすすめします。

a. 最新版にアップグレードする

この脆弱性の修正版(1.2.12 / 1.3.16 / 2.2.8 / 2.3.4)がリリースされていますので、こちらのバージョンへアップグレードして下さい。

Security Release – CakePHP 1.2.12, 1.3.16, 2.2.8 and 2.3.4 :: The Bakery: Everything CakePHP

b. 修正箇所を自分で適用する

ただちに CakePHP のアップグレードができないようであれば、今回の脆弱性に関する修正箇所を自分で適用する方法もあります。
各バージョンごとに差分を確認して適用を行なって下さい。

CakePHP を利用した OSS も対応を

CakePHP 自体の脆弱性なので、CakePHP をベースとした OSS もこの脆弱性が存在する可能性があります。随時それぞれの OSS にてセキュリティフィックス版がリリースされるかと思いますが、まだの場合は上記のとおりアップグレードを検討して下さい。

  • baserCMS は、2.1.1にてセキュリティフィックス版(1.2.12)に更新されています。
  • candycane は、master ブランチにてセキュリティフィックス版(2.3.4)に更新されています。
  • コメント (Close): 0
  • トラックバック (Close): 0

Amazon S3 stream wrapper で S3 を操作する

この記事の所要時間: 038

AWS SDK for PHP2 に実装されている Amazon S3 stream wrapper で S3 を操作してみました。

Amazon S3 stream wrapper を使うと「s3://bucket/foo/bar.txt」といったパスで mkdir() や file_get_contents() などの標準関数から S3 を操作することができます。

Amazon S3 stream wrapper の使い方

Amazon S3 stream wrapper は AWS SDK for PHP2 に含まれているので、SDK をインストールしておきます。インストール方法などは下記をどうぞ。

AWS SDK for PHP 2 をインストールして AutoScaling の設定を行う

Aws\S3\S3Client の registerStreamWrapper メソッドを実行すると「s3」というプロトコルが有効となります。
あとは通常のファイル操作と同じように mkdir() や file_get_contents() 関数にて操作対象の S3 オブジェクトを操作します。

パス名は以下の形式で指定します。

s3://バケット名/キー(パス)

たとえば bucket1 というバケットの /folder/foo.txt であれば下記のようになります。

s3://bucket1/folder/foo.txt

以下のサンプルでは、東京リージョンに存在するバケットに対して、dir1/dir2 というフォルダを作成して、file1, file2, file3 というファイルをアップロードしています。さらに dir1/dir2 の内容を読み込んで echo しています。

これを実行すると以下のように出力されます。

$ php s3_stream_wrapper.php
s3://shin1x1-tokyo/dir1/dir2/file1.txt = file1
s3://shin1x1-tokyo/dir1/dir2/file2.txt = file2
s3://shin1x1-tokyo/dir1/dir2/file3.txt = file3

Management Console でも S3 にオブジェクトが作成されていることが分かります。

s3_stream_wrapper

Amazon S3 stream wrapper を使う利点

stream wrapper で S3 を操作する利点ですが、まず普段ファイルを操作するのと同じ方法で操作できるのが便利です。

また、スキーマを変更するだけで別のプロトコルで処理ができるので、ユニットテストが書きやすくなります。

具体的には、「s3://」といったパスを引数で渡して処理を実行するように実装しておきます。すると、テスト時は vfsStream を使って「vfs://」からはじまるパス名に渡すように変更すれば、S3 へ通信させることなくテストを実行することができます。

SDK の API を実行するよりも簡単にS3 を操作できるのでおすすめです。

参考

  • コメント (Close): 0
  • トラックバック (Close): 0

PHP5.4 で Zend OPcache をインストールしてベンチマークを取ってみた

  • 2013-05-01 (水)
  • PHP
この記事の所要時間: 441

PHP5.5 から標準バンドルされる Zend OPcache を PHP5.4 にインストールしてみました。

インストールする環境は Vagrant 上の CentOS6.4 です。PHP は remi リポジトリからインストールしています。

$ php -v
PHP 5.4.14 (cli) (built: Apr 11 2013 11:04:32)
  Copyright (c) 1997-2013 The PHP Group
  Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

Zend OPcache のインストール

remi リポジトリには Zend OPcache は存在しないようなので、github からソースをダウンロードしてビルドしました。
手順は Zend OPcache の github ページに記載されている内容そのままです。

なおビルドに際して php-devel が必要となるので、これもインストールしておきます。

$ sudo yum install php-devel --enablerepo=remi

$ git clone https://github.com/zend-dev/ZendOptimizerPlus.git
$ cd ZendOptimizerPlus
$ phpize
$ ./configure --with-php-config=/usr/bin/php-config
$ make
$ make install

これで /usr/lib64/php/modules/ 以下に opcache.so が作成されます。(ディレクトリは環境によって異なります。)

$ ls /usr/lib64/php/modules/opcache.so
/usr/lib64/php/modules/opcache.so

あとは php.ini にて、opcache.so を読み込むように設定を追加します。

$ sud vim /etc/php.ini
; 以下を追加
zend_extension=/usr/lib64/php/modules/opcache.so

php -v を実行すると 「with Zend OPcache」表示され、Zend OPcache が有効になっていることが分かります。

$ php -v
PHP 5.4.14 (cli) (built: Apr 11 2013 11:04:32)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
  with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies

ベンチマーク

Zend OPcache の効果を確認するために簡単なベンチマークを取ってみます。

  • ベンチマークは ab にて行う( ab -c 50 -n 1000 http://localhost/helllo )
  • httpd stop & start 後に6 回計測して、5回分の平均値を算出(初回はキャッシュ処理を行うので除外)
  • 対象アプリケーションは CakePHP2.3.2 で “Hello!” を表示するだけのもの。(ソース

PHP のみ、PHP + Zend OPcache の他に比較として PHP + APC(3.1.13 / pecl でインストール)も計測しました。

結果は以下になります。
Zend OPcache を組み込むと 5 倍近くパフォーマンスが向上しています。APC も速くなっていますが、Zend OPcache の方が 20% ほど速いようです。

Requests per second Rate
PHP5.4.14 49.41 1
PHP5.4.14 + APC 3.1.13 215.3 4.3
PHP5.4.14 + Zend OPcache 7.0.2-dev 258.4 5.2

ためしに Zend OPcache と APC を同時に有効にしてみましたが、サンプルアプリケーションでは問題無く動作しました:D

PHP5.4 で使うなら Zend OPcache ? APC ?

ここ数年は PHP でコードキャッシュなら APC が定番でしたが、PHP5.4 以降対応版がまだ beta となっています(概ね問題無いようですが)。一方、Zend OPcache はパフォーマンスで APC と同等もしくは上回っており、PHP5.5 からは標準バンドルされるということで、今後を考えると Zend OPcache を利用するのが良さそうです。

ただし Zend OPcache 自体もまだ開発が進んでいる段階ですので、本番環境での利用についてはリスクを承知の上でお願いします。

  • コメント (Close): 0
  • トラックバック (Close): 0

Home > アーカイブ > 2013-05

検索
フィード
メタ情報

Return to page top