PHP: pecl_http v2 を導入する
phpbrew で導入した際に少し手間取ったので、記録に残しておくpecl_http v2 は raphf と propro に依存しているので、 これらの PECL モジュールを先にインストールしておく必要がある。 phpbrew ext install raphf phpbrew ext install propro phpbrew ext install pecl_http 上記のコマンドを実行した後で pecl_http のクラスを利用しようとしても、raphf モジュールがすでにロードされたという警告と、クラスが定義されていないというエラーが表示される。 Warning: Module 'raphf' already loaded in Unknown on line 0 PHP Fatal error: Class 'http\Message' not found in /Us
PHP: Guzzle 5 で HTTP リクエストを送信する
Guzzle 5 で Promise による非同期通信がサポートされるようになった。Composer によるセットアップは次のとおり。 composer require guzzlehttp/guzzle:* POST リクエストを送信してみよう。 require 'vendor/autoload.php'; $client = new GuzzleHttp\Client(); $client ->post( 'http://httpbin.org/post', [ 'future' => true, 'body' => 'foo=bar' ] ) ->then(function ($response) { var_dump( $response->getStatusCode(), $response->getHeader('Content-Type'), (string) $respon
PHP ではインターフェイスのメソッドを抽象クラスの抽象メソッドに割り当てることができない
2011年11月27日追記：PHP 5.4RC2 でこのバグは修正されました。 Interface implementation / inheritence not possible in abstract classes13.4.5 抽象クラスとインターフェイス (C#)抽象クラスは抽象クラスを継承できるが、抽象メソッドを再定義することはできないC# ではインターフェイスから継承したメソッドを抽象メソッドに割り当てることができますが、PHP は割り当てることはできません。 interface A { function foo(); } abstract class B implements A { abstract public function foo(); } class C extends B { public function foo() { echo 'works',PHP_E
new self と new static の違い
New self vs. new static stackoverflow.com self は記述されたクラスに束縛されるのに対して、static は呼び手のクラスに束縛される。 class A { public static function getSelfName() { return get_class(new self()); } public static function getStaticName() { return get_class(new static()); } } class B extends A { public static function getParentName() { return get_class(new parent()); } } echo A::getSelfName(),PHP_EOL; //A echo B::getSelfName
PHP 5.6 で導入が予定される機能 (9月時点)
PHP 5.5 リリースから3ヶ月しか経っていないけれど、いくつかの RFC を取り上げる。まずは Silex の開発者である Igor Wiedler さんが提案した名前空間つきの関数のインポート (RFC: Importing namespaced functions)が受理された。関数だけで構成された小さなライブラリ、ドメイン特化言語、フォールバックに役立つ。 namespace foo\bar { function baz() { return 'foo.bar.baz'; } function qux() { return baz(); } const baz = 42; } namespace { use function foo\bar\baz, foo\bar\qux; use const foo\bar\baz; var_dump(baz()); var_dump(qux
Unicode の制御コードが含まれるかチェックする
Unicode の制御コードが含まれるかチェックする英数字が含まれるかチェックする英字が含まれるかチェックする半角数字が含まれるかチェックする ヌルバイト(U+0000) などの制御コード(制御文字)によって脆弱性が生み出される可能性があることと日常の文章のやりとりでは不要な文字なので、制御コードが存在するかどうかをチェックする必要がある。 制御コードの集合は C0 と C1 と呼ばれる。C0 のコードポイントの範囲は U+0000 から U+001F と U+007F であり、C1 のコードポイントの範囲は U+0080 から U+009F である。Unicode.org で配布されている C0 の定義と説明はこちら、C1 はこちらのリンクを参照。Wikipedia の C0 and C1 control codes やUnicode control characters の記事が存在す
PHP 5.5 以降の不正なバイト列を処理する関数の選択について
Unicode に関する認知バイアスと教材の改善PHP の文字列関数の将来についてmbstring を標準モジュールに変更する場合の検討課題GPL、LGPL ではない Unicode ライブラリはかぎられているPHP における文字列型 (PHP 公式マニュアル)UTF-8 未対応の文字列関数のリスト文字列関数の抽象化ライブラリはあまり意味がないPHP 5.5 以降の不正なバイト列を処理する関数の選択についてmb_convert_encoding の引数の改善案UTF-8 の不正なバイト列を代替文字に置き換えるオプションを json_encode に追加する必要性ロケールの影響を受ける関数 PHP 5.4 で htmlspecialchars の ENT_SUBSTITUTE オプション、mbstring 拡張モジュールの mb_substitute_character による代替文字の指定
PHP の後方互換性に関する誤解と計画的廃棄の必要性
PHP はバージョンアップが多く、後方互換性があまり守られない言語だと非難めいたことが言われるが、公式マニュアルの付録のアップグレードガイドを見ると、はたしてそれが本当なのかというのは疑問である。 ほかのスクリプト言語と比較すると、PHP はウェブアプリケーションに特化した言語であるために、修正の影響がどこに及ぶのか予想しやすいし、ドキュメントの分量はそれほど大きくない。 また、削除される機能は後世から見て導入が不適切であると考えられている機能なので、バージョンアップがむずかしいということは、不適切であると考える機能をたくさん使う残念なコードベースになっているのではないだろうか。それを言語のせいにするのは帰属の誤りである。 問題は PHP のバージョンアップが盛んであることではなく、どの PHP のバージョンをターゲットにすれば広く採用してもらえるかとか、 古い PHP バージョンを対象と
PHP 5.5 で mysql 拡張モジュールが非推奨になり、将来において WordPress を筆頭にさまざまな CMS のアップグレード作業が必要になります
PHP 5.5 で mysql 拡張モジュールが非推奨になり、E_DEPRECATED エラーが表示されるようになりました。将来の PHP のバージョンで削除されます。 mysql 拡張モジュールに依存する CMS を使ってサイトを運用している場合、将来、運用サーバーに導入されている PHP のバージョンの切り替えに備えて、 mysqli もしくは PDO に対応した CMS のバージョンへのアップグレードするか、別の CMS やウェブサービスに切り替える必要があります。 多くの PHP 製の CMS が共有ホスティングにインストールされており、共有ホスティングは比較的古い PHP のバージョンのサポートを続ける傾向にありますが、古い PHP のバージョンを使い続ける場合、PHP のバグやセキュリティの未対応、より新しい PHP のバージョンを最小バージョンとするライブラリや CMS を導
スーパーグローバルとフィルター関数の使いわけ
一般的にグローバル変数はよくないものだと言われるが、それはミュータブルなグローバル変数という条件のもとであって、イミュータブルなグローバル変数であれば問題ない。 ミュータブルなグローバル変数の場合、プログラムコードのどこかで書き換えられてしまうとほかのところにも悪影響がある。 一方、イミュータブルなグローバル変数であれば、書き換えることができないので、プログラムのどこからアクセスしても安全である。 Haskell や Scala といった関数型言語の場合、基本的に変数はイミュータブルである。 PHP の場合、スーパーグローバルはミュータブルなので、PHP フレームワークはこの問題を回避するために、これらのスーパーグローバルの値を専用のオブジェクトに保存してからアクセスするというやりかたを採用している。専用のクラスを導入したくないのであれば、GET、POST、Cookie に関して、filt
文字列の要素が許可された文字だけであることのバリデーションを行う
jQuery Validation プラグインを使う文字列の要素が許可された文字だけであることのバリデーションを行う入力時における JavaScript のバリデーションをサーバーサイドに任せる投稿できる状態になるまでカウントダウンを表示する二重送信を防止する パスワードやユーザー名の登録において、指定した文字だけが使われることを確認する必要がある場合、許可する文字を配列にして、in_array 関数を使えばよい。 function validate_string($string, $additinal_chars = []) { $allowed_chars = array_merge([ '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j',
PHP 5.5 でパスワードハッシュ関数が導入される
PHP 5.5 でパスワードハッシュ関数が導入されるPHP: パスワードハッシュライブラリのコードスニペットPHP: PBKDF2 を使ってパスワードハッシュを生成するPHP: 疑似乱数の文字列を生成するPHP: openssl_random_pseudo_bytes で疑似乱数を生成するPHP: openssl_random_pseudo_bytes と mcrypt_create_iv の比較PHP: フォームに CSRF 対策のトークンを導入するPHP: フォームに CSRF 対策のトークンを導入する (その2)JavaScript: CSRF 対策のトークンヘッダーを送信する PHP 5.5 でパスワードハッシュ関数が導入され、パスワードハッシュのストレッチングおよびユーザーから入力されたパスワードとハッシュのバリデーションをかんたんにできるようになった。 require_once
PHP: openssl_random_pseudo_bytes で疑似乱数を生成する
PHP 5.5 でパスワードハッシュ関数が導入されるPHP: パスワードハッシュライブラリのコードスニペットPHP: PBKDF2 を使ってパスワードハッシュを生成するPHP: 疑似乱数の文字列を生成するPHP: openssl_random_pseudo_bytes で疑似乱数を生成するPHP: openssl_random_pseudo_bytes と mcrypt_create_iv の比較PHP: フォームに CSRF 対策のトークンを導入するPHP: フォームに CSRF 対策のトークンを導入する (その2)JavaScript: CSRF 対策のトークンヘッダーを送信するBetter Random Numbers in PHP using /dev/urandom に mcrypt_create_iv を使って疑似乱数を生成するコードが掲載されているので、これを openssl
PHP: openssl_random_pseudo_bytes と mcrypt_create_iv の比較
PHP 5.5 でパスワードハッシュ関数が導入されるPHP: パスワードハッシュライブラリのコードスニペットPHP: PBKDF2 を使ってパスワードハッシュを生成するPHP: 疑似乱数の文字列を生成するPHP: openssl_random_pseudo_bytes で疑似乱数を生成するPHP: openssl_random_pseudo_bytes と mcrypt_create_iv の比較PHP: フォームに CSRF 対策のトークンを導入するPHP: フォームに CSRF 対策のトークンを導入する (その2)JavaScript: CSRF 対策のトークンヘッダーを送信する ランダムな文字列を生成するにはファイル関数を使って /dev/urandom に直接アクセスするやりかたがもっとも明快であり、OS のしくみを学ぶ機会を提供するので、教育的でもある。徳丸本でもそのやりかたが採
Symfony2: OptionsResolver を使って FizzBuzz 問題に取り組む
OptionsResolver では、クロージャを使い、評価を遅延させることで、ほかの要素に依存する要素の値を動的に決めることができる。 依存関係にある要素の組み合わせの例としてもっとも目にするのは関数のように入力値と出力値の組み合わせである。そこで OptionResolver を使って FizzBuzz 問題に取り組んでみた。 use Symfony\Component\OptionsResolver\OptionsResolver; use Symfony\Component\OptionsResolver\OptionsResolverInterface; use Symfony\Component\OptionsResolver\Options; require_once 'vendor/autoload.php'; $resolver = new OptionsResolver
Symfony2: OptionsResolver を試す
Symfony 2.1 で OptionsResolver が導入された。Composer でダウンロードするには composer.json に次のように書く。 { "require": { "symfony/options-resolver": "2.1.*" } } README では setDefaults、setAllowedValues、setRequired、resolve メソッドの用例が示されているので、具体的な値を代入して試してみよう。 use Symfony\Component\OptionsResolver\OptionsResolver; use Symfony\Component\OptionsResolver\OptionsResolverInterface; use Symfony\Component\OptionsResolver\Options; req
クロージャデザインパターン (PHP 版)
2013年4月13日追記: PHP 5.5 で finally 句が追加されたので Loan パターンを追記しました。 Closure Design Patterns で紹介されている Groovy のコードを PHP に翻訳しました。無名関数とクロージャを区別しても情報が分散してしまうのでクロージャに統一しました。Method Combination (関数合成)は省略しました。原文ではカリー化(currying) と書いている箇所を部分適用 (partial application) に訂正しました。カリー化と部分適用の違いについてはこちらのブログに解説があります。Groovy コアに本当のカリー化メソッドを採用することへの要望があり、長期的には取り込まれる見込みのようです。 これらのパターンは Venkat Subramaniam 氏および Neal Ford 氏のプレゼン資料から抜
ダイジェスト認証の短所
英語版 Wikipedia の記事からダイジェスト認証の短所の箇所を翻訳した。 RFC 2617 がオプションでないため、サーバーによって qop (quality-of-protection) が指定されなければ、レガシーな RFC 2069 の古いモードでクライアントが実行される。中間者攻撃に対して脆弱性がある。たとえば、中間者攻撃をしかける側が BASIC 認証もしくはレガシーな RFC 2069 を使うようにクライアントに指示することができる。さらに、ダイジェストアクセス認証にはサーバーの一意性を検証するメカニズムをクライアントに提供しない。 サーバーのなかには復号可能な暗号によってパスワードを保存することを要求するものがある。しかしながら、ユーザ名、領域、パスワードをダイジェスト処理されたものを保存することはできる。パスワードを保存する場合に bcrypt のような強度の強いパス
関数をオートロードする
PHP のオートロードの対象はクラスだけなので、関数を単独でロードさせることはできないが、オブジェクトを生成するもしくはスタティックメソッドを実行すれば、クラスの定義ファイルが読み込まれるので、同じファイルで定義されている関数も自動的に利用できるようになる。ただし、スタティックメソッドを使った場合とあまり入力する手間は変わらない。 PHP コアの RFC によれば、関数をオートロードできるようにする機能の導入は何度か検討されているが、今の時点では導入されていない。 require_once __DIR__.'/vendor/autoload.php'; use Symfony\Component\ClassLoader\UniversalClassLoader; use MyApp\MyFunc; $loader = new UniversalClassLoader(); $loader-
PHP: コールバック関数でキーをフィルタリングする
PHP: array_map のコールバック関数がキーを受け付けるようにするPHP: コールバック関数でキーをフィルタリングするPHP: filter と map を1つにまとめた関数を定義するPHP: filter と partitionPHP で zip、unzip、zipWitharray_fill にコールバック関数を受け付ける機能を追加するHaskell の Data.Map モジュールの filterWithKey 関数を使ってみて、PHP 版がほしくなったので。 まずは素直に foreach 文を使った定義。 function array_filter_with_key(array $array, callable $callback) { $ret = []; foreach($array as $key => $value) { if ($callback($key))
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
