PHP 7.2以降におけるPDO::PARAM_INTの仕様変更
サマリ PHP 7.2以降、PDOの内部実装が変更された。動的プレースホルダ（エミュレーションOFF）にてバインド時にPDO::PARAM_INTを指定した場合、PHP 7.1までは文字列型としてバインドされていたが、PHP 7.2以降では整数型としてバインドされる。 この変更により、従来PDOが内包していた「暗黙の型変換」は解消される一方、integerへの暗黙のキャストにより、整数の最大値を超えた場合に不具合が発生する可能性がある。 この記事を読むのに必要な前提知識 この記事は、以前の記事（下記）の続編のような形になっています。 PDOのサンプルで数値をバインドする際にintにキャストしている理由 この記事では、PDOを用いたサンプルスクリプトでbindValue時にinteger型へのキャストを明示している理由を説明しています。パラメータを文字列として渡した場合、PDO::PARAM
PHPのmysqlndの圧縮プロトコルについてのメモ - hnwの日記
PHP+PDO+MySQLの環境では、PHP-MySQL間の通信についてzlibを使った圧縮プロトコルを利用することができます。この機能は、DBサーバのCPU利用率に十分余裕があり、かつPHP-MySQL間のネットワーク帯域が逼迫している状況で有用です。 MySQLの圧縮プロトコルとそのマニュアル PHP+MySQLの環境で、圧縮プロトコルは下記のようなコードで利用できます。 <?php $options = [ PDO::MYSQL_ATTR_COMPRESS => true ]; $db = new PDO($dsn, $user, $pass, $options); MySQLドライバとしてmysqlndを利用している場合*1、PHP 5.3.11（2012年4月リリース）以降であれば圧縮プロトコルに対応しています。このことはPHPマニュアルにも下記の通り記載があります。 PDO::
PDOに複文実行を禁止するオプションが追加されていた
エグゼクティブサマリ PHP 5.5.21、PHP 5.6.5 以降、PHPにPDO::MYSQL_ATTR_MULTI_STATEMENTSというオプションが追加され、PDO+MySQLの組み合わせで、SQLの複文を禁止できるようになった。この設定はSQLインジェクションの緩和策として有効である。 はじめに 2013年12月に公開した PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能 にて、PDOとMySQLの組み合わせで、SQLインジェクションの文脈で複文呼び出しが可能であることを報告していましたが、その後のPHPのバージョンアップで、複文実行を禁止するオプションが追加されていましたので報告します。 対象のバージョンは以下の通りです。 PHP 5.5.21 以降 PHP 5.6.5 以降 全ての PHP 7.0、7.1 前述の記事を書いた後、3大
PDOのサンプルで数値をバインドする際にintにキャストしている理由
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
突然のUnbuffered Query…PDO+MySQLで入り込んだ迷宮 - Qiita
CodeIgniterをバージョンアップしたところ、思わぬ形でPHPのバグを踏んでしまいました。 MySQLのバッファモード トラブルに見舞われるまで知らなかったのですが、PHPからMySQLを使う場合には、「バッファモード」と「非バッファモード」があります（リファレンス）。 バッファモード…SQLを発行すると、自動的にPHP側へ全データを取ってくる。デフォルト設定。 非バッファモード…SQLを発行した段階ではまだデータを取ってこない。 一見すると、非バッファモードのほうが便利そうに見えるのですが、1つ大きな問題があります。非バッファモードの場合、一度投げたクエリを始末し切るまで次のクエリが投げられないのです。もちろん、それを意識した上でPDOなりMySQLiなりを直接叩くのであればまだ使いでもあるのですが、（非バッファモードに対応しない）フレームワーク経由でDB接続するとなると、どこでク
fuelPHP で PDOを使ってOracle接続する時の注意点 その3 | トミリュウ・コム
fuelPHPでPDOを使ってOracle接続する時の注意点 の３つ目のトピックです。 fuelPHPでサポートされるデータベース接続のためのドライバは「MySQL、MySQLiそしてPDOです。」とfuelのマニュアルにも記載されています。したがって、Oracleをデータベースとして選択する場合はPDO(PHP Data Object)でのアクセスとなり、PHPにもPDO_OCIの拡張モジュールが必要になります。拡張モジュールのインストールについては別の機会に述べるとして、ここではfuelPHPでPDO_OCIでOracleデータベースと接続する場合のコンフィグ・パラメータ設定の注意点について記しておきます。 結論から先に述べると、fuelPHPでPDO_OCIを使ってOracle接続する場合は、db.phpのコンフィグ設定で ‘persistent’ 設定はtrueではなく必ずfals
FuelPHPからSQL Serverへの接続するときのdb.phpの書き方 | blog@kenzauros.com
FuelPHPからデータベースに接続するにはdb.phpを編集すればいいのだが、Microsoft SQL Serverへの接続がうまくいかなかったので、設定方法をメモしておく。 動作環境 Windows Server 2012 R2 (x64) PHP 5.6.11 (x64) SQL Server 2014 FuelPHP 1.7.3 要件 FuelPHPにはSQL Serverの専用コネクタがないので、PDO(PHP Data Object)を用いる。なお、PHPにpdo_sqlsrvドライバーがインストールされている必要がある。 db.phpの設定 fuel/app/config/db.phpやfuel/app/config/development/db.phpの内容は下記のように設定する。 return array( 'default' => array( 'type' => '
fuelPHP で PDOを使ってOracle接続する時の注意点 | トミリュウ・コム
fuelPHPフレームワークを使ってPDOでOracleに接続する場合に、普通にデータベース接続のコンフィグ設定を行っても標準のままだとfuelのエラーが表示されてしまいます。 ↓こんなエラーメッセージ PDOException [ HY000 ]: SQLSTATE[HY000]: General error: 922 OCIStmtExecute: ORA-00922: missing or invalid option (ext\pdo_oci\oci_driver.c:341) 原因は、 /classes/database/pdo/connection.php の174行目あたりですが、 「SET NAMES utf8」 というコマンドをSQLで発行している箇所で、Oracleにはそのようなコマンドはありません。（MySQLにはありますが。。。） Oracleにないコマンドを実行し
FuelPHP:PDO+PostgreSQLで、insert時にidがとれないエラーを回避する - Qiita
問題 FuelPHPのModel_Crudを継承したモデルでcreateを行うと、生成後のidがとれず下記のようなエラーとなる Property "id" not found for Model_Monkey. in /vagrant_data/html/fuelphp/fuel/core/classes/model/crud.php on line 441 これはPDOのlastInsertId()を使って生成後のidをとってきているのが原因。PDOのlastInsertId()はPostgreSQLでは最後に追加したidを返さない。 対策 PostgreSQLでserial型(mysqlでいうところのauto_increment相当)を使う場合にはinsert文の最後に returning 節をつけることでidを返すことができる
PHP: MySQL (PDO) - Manual
はじめに PDO_MYSQL は、PHP から MySQL データベースへのアクセスを可能にするための PHP Data Objects (PDO) インターフェイス を実装したドライバです。 PDO_MYSQLは、 デフォルトでエミュレートされたプリペアドステートメントを使います。 MySQL 8 PHP 7.1.16 より前のバージョン、もしくは PHP 7.2.4 より前の 7.2系の PHP では、 MySQL 8 サーバーのデフォルトパスワードプラグインを mysql_native_password に設定するようにしてください。 さもないと、 The server requested authentication method unknown to the client [caching_sha2_password] のようなエラーを見ることになります。たとえあなたが cach
fuelphpに挑戦したところ文字化けで爆ハマり
色々なことをやりすぎてどれが根本原因だったのかわからなかったです＼(^o^)／ が、試した過程を残して大体このあたり感を出します＼(^o^)／ fuelphpは全く悪くないです＼(^o^)／ 現象：DBから取得した内容が文字化けする。 環境： fuelphp 1.7 centos 6.5 php 5.3.3 myql 5.5系 調査１：DBの文字コード設定 mysqlに接続して中の値を見ると、ちゃんと表示されていました。 よくありがちなこの時点で?になるパターンではなかったのですが、 方々を見て一部追加。 [mysqld] character-set-server = utf8 はしていた。 ※この時点でのshow variablesの結果は覚えていないです。スイマセン・・・。 追加 [mysqld] skip-character-set-client-handshake [client]
PDO から Doctrine DBAL への書き換え
PDO から Doctrine DBAL への書き換えDoctrine2: PDO を使うコードを Doctrine ORM に書き換える学習内容Doctrine DBAL についてDoctrine DBAL のセットアップSymfony、Silex との連携テーブルの作成とデータの投入PDO のコードDoctrine DBAL のコードSQL 実行と結果セット取得メソッドの種類型の種類その他の検討項目プレースホルダの形式bindValue と bindParam結果セットの形式を指定する場所学習内容 SQL の SELECT のプリペアドステートメントを実行する PDO のコードと Doctrine DBAL のコードを比較することで Doctrine DBAL をはじめて使う際の心理的抵抗感を減らす。プリペアドステートメントと暗黙の型変換による SQL インジェクションについて学ぶ。さ
limonade + idiorm でさわやかコーディングのメモ | もしもワークス
こないだ仕事で使った組み合わせ。 Limonade（Lemonadeではない）はSinatraに影響を受けたらしいPHP用の軽量フレームワーク。IdiormはPDOベース。どちらもシンプルでプロトタイプ作りに適している。覚えることが少ないから学習も簡単。IdiormをベースにしたORマッパー、Parisはまだ使ってないので後で確かめたい。 Limonade – PHP micro-framework Idiorm and Paris – object relational mapper (ORM), fluent SQL query builder and Active Record implementation for PHP 以下はlimonadeでidiormを使うときのメモ。 接続設定やエラーモードの指定などを、index.phpのconfigure()に記述。 require
PDOでオブジェクトをフェッチ＆JSONとCSVファイル出力 - Qiita
PDOを使ったデータベース操作でオブジェクトを扱う場合、不便なところが結構あります。 それを PDOStatement を拡張することで使いやすくしようという話を基本に、応用例としてJSON出力とCSVファイル出力の方法を紹介します。 オブジェクトで取得するためのフェッチモード フェッチモードには多彩なものが用意されているのですが、オブジェクトで取得する場合はどれも使いづらいです。 自分はいわゆるモデルクラスは不変オブジェクトにしたいよ派かつ、マジックメソッド大好きなので、その辺りの使いやすさについても注目してみます。 PDO::FETCH_OBJ 列名をプロパティに持つ匿名オブジェクト (stdClass) を返します。 匿名オブジェクトなんて連想配列と同じだし、今となっては意味がなさそう…。 PDO::FETCH_LAZY PHPマニュアルの記述からは PDO::FETCH_OBJ と
PDOでの数値列の扱いにはワナがいっぱい（2） — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
PHP Advent Calendar 2013 in Adventarの18日目です。昨日は、takc923さんの「PHPのissetの罠」でした。 「PDOでの数値列の扱いにはワナがいっぱい」を書いたところ、以下のように結構反響がありました。 PDOでの数値列の扱いにはワナがいっぱい — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something http://t.co/kDJAWzdMqr | 先日思いっきりハマったところ。 — K.K. (@kkmym) December 16, 2013 他の方も書いてるけど、バインドで型を明示すればおｋ / “PDOでの数値列の扱いにはワナがいっぱい — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or somethin
PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能
基礎からのPHPという書籍を読んでおりましたら、SQLインジェクションの攻撃例として、以下のSQL文ができあがる例が紹介されていました。PHP+PDO+MySQLという組み合わせです。 SELECT * FROM tb2 WHERE ban=1;delete from tb2 2つのSQL文がセミコロンで区切って1つにまとめられていますが、これを「複文(multiple statement)」と言います。私は、SQLインジェクション攻撃の文脈で複文が使える組み合わせを調べたことがあり、PHPとMySQLという組み合わせでは、複文は使えないと思っていましたので、この攻撃は成立しないのではないかと思いました。 しかし、決めつけも良くないと思い手元の環境で動かしてみたところ、あっさり動くではありませんか。 PDOを用いてMySQLを呼び出す場合は複文が実行できると気づきましたが、なぜPDOの場合
PDOでの数値列の扱いにはワナがいっぱい — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
PHP Advent Calendar 2013 in Adventarの15日目です。 みなさん、史上空前のSQLのエスケープブームの中、いかがお過ごしでしょうか？ なお、「我が社のプリペアドステートメントは大丈夫なのか？」という疑問をお持ちの方には、以下の記事をお薦めします。 漢(オトコ)のコンピュータ道: SQLインジェクション対策に正解はない さて、あまりにエスケープが人気なので、プリペアドステートメントにもう少しがんばってもらいたい気がしました。そこで、今日は、以下の徳丸さんの大変に力作な記事に関連した、PDOでのプリペアドステートメントについての記事を書いてみたいと思います。 PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた | 徳丸浩の日記 一応、今でこそPDOは普通に使われていますが、細かい点までみていくと、仕様なのかバグなのか、あるいはこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Koriym.DevPdoStatement/README.ja.md at 1.x · koriym/Koriym.DevPdoStatement
GitHub - panique/pdo-debug: Emulates the SQL query constructed by PDO. The magic behind: A simple function that combines your parameters and the raw query. Not perfect, but does the job.
GitHub - nineinchnick/pdo_oci8: PHP userspace classes for Oracle to mimic the PDO interface while wrapping the oci8 functions.