カテゴリー: Web開発

PEAR の CacheLite を、短期キャッシュと長期キャッシュに分けて運用する場合、普通に automaticCleaningFactor を使っていると、思った通りに動作しなくなります。
 
automaticCleaningFactor は、現在設定されているlifeTimeを基準に、cache_dirの中の全ての古いファイルを掃除してしまいます。
 
save() で指定した group_id の古いファイル限定で掃除してくれれば融通がき くのですが、そもそも clean() の実装がそうはなっていない様子。
 
PEAR Bugにもこの問題が報告されていますが、現在のAPIを変えずに実装するのは困難として対応打ち切りになっています。
その代わり、解決案としてキャッシュの寿命別にフォルダ分けをする方法が紹介されていました。
 

Best practice then would appear to be that you create directories for each of your caches if you want to be using this autocleanfactor.
ここでの最良の習慣は、autocleanfactorを使う場合には(用途,寿命の違う)それぞれのキャッシュごとにディレクトリを分けて作る事です。

 
参考:
– non-specific automaticCleaningFactor(PEAR Bug)
– Cache_Lite(PEARマニュアル)

レコード…連想配列の配列…は、MDB::fetchAll() や DB::getAll() の結果の書式で見られるように一般的なデータ構造書式です。
たまにはコードを上げてみよう、ということで汎用関数としてレコードソート関数を作ってみました。実装コードおよびサンプルは下のほうにあります。
特に著作権等は主張しませんのでご自由にお使いください。
 
書式：

int sort_records(&$records, $key, $descent = false);

---

実装コード:

/**
 * DBなどのレコードを任意のキーでソートする。
 * PHP 4.4.9, PHP 5.2.8 で動作確認。
 *
 * @author ecoop.net
 * @access public
 * @param array &$records DBなどレコードの配列
 * @param string $key ソートの基準にするカラムの名前。省略時は第一カラムでソート。
 * @param boolean $descent true なら降順で結果を返す。省略時は false
 * @return bool 成功なら true を返す
 */
function sort_records(&$records, $key = null, $descent = false){
  if(!$records || !is_array($records)){ return false; }
   
  // $key が省略された場合は第一レコードの第一カラムを名前を取得
  if(is_null($key)){
    $t = array_values($records);
    $t = array_keys($t[0]);
    if(!$t){ return false; }
    $key = $t[0];
  }
  // —-
  $map = array();
  foreach($records as $i => $v){
    if(!is_array($v) || !isset($v[$key])){ return false; }
    $map[$v[$key] .’_’. $i] = $v;
  }
  
  if($descent){
    $res = krsort($map);
  }else{
    $res = ksort($map);
  }
  $records = array_values($map);
  return $res;
}

利用例:

// 元データ
$records = array(
array(‘age’ => 24, ‘name’=>’john’),
        array(‘age’ => 33, ‘name’=>’george’),
        array(‘age’ => 56, ‘name’=>’bill’),
        array(‘age’ => 50, ‘name’=>’steven’),
);
// name カラムでソート
sort_records($records, ‘name’);
print_r($records);

結果:

Array
(
    [0] => Array
        (
            [age] => 56
            [name] => bill
        )
    [1] => Array
        (
            [age] => 33
            [name] => george
        )
    [2] => Array
        (
            [age] => 24
            [name] => john
        )
    [3] => Array
        (
            [age] => 50
            [name] => steven
        )
)

CSRF 対策のうち、セッションフィクセーションを避けるために使われる
session_regenerate_id() 関数について、ITProで間違い(になる場合がある)記事を見つけたのでメモ。
 
関数の知られざる引数（print_r関数、session_regenerate_id関数）[より

同じように、PHP 5.1からはsession_regenerate_id関数にも第1引数が指定されました。第1引数をtrueに指定すると、古くなったセッションは削除されるようになります。
 
もともとセッション固定攻撃を防ぐために用意された関数ではなく、PHP 5.1 までの同関数には古いセッションファイルを削除する機能が無かったため、セッション固定攻撃への対策としては不十分でした。
 
今後は、session_regenerate_id関数の引数に必ずtrueを指定することを忘れないようにしましょう。また、それまでのPHPで使う場合は、以下のコードを使うことで、セッション固定攻撃を防ぐことができます。

のように、session_regenerate_id() の第一引数に true を常に指定すべきと書かれていますが、session_regenerate_id(true) はむやみに使ってはなりません。
 
ショッピングカートなど限定的な用途でセッションを使っている場合は問題ないのですが、常にログインが必要なサイトなどで非同期で複数のリクエストを実行する可能性がある場合、古いセッションが削除されると問題になりことがあります。
 
たとえば同じ HTML 内に認証が必要な画像などの埋め込みコンテンツが複数あったり AJAX で認証が必要なデータにアクセスする場合、一つのセッションIDで複数のリクエストを行うため、2リクエスト目以降も古いセッションで認証することになるからです。
 
代替案として、session_regenerate_id(false) と session_write_close() を組み合わせて古いセッションのみ有効期間を設定してやるとよい、とsession_regenrate_idのコメント欄に書かれていました。
 
実装例:

// ユーザがリクエストしたセッションIDからセッション情報をロードする。
session_start();
// —————————————————–
// 以下セッションフィクセーション対策
if(isset($_SESSION[‘expire’]) && $_SESSION[‘expire’] < time()){
    // 過去に session_regenerate_id() で置き換えられた古いセッションによるアクセス。
    // 有効期限を過ぎていればセッション情報をクリアする。
    $_SESSION = array();
}
 
// 古いセッションは2分間で消えるように設定。
$_SESSION[‘expire’] = time() + (2*60);
// 有効期限を記録するため、一旦明示的にセッションを閉じ、$_SESSION の中身を古いセッションIDで保存する。
session_write_close();
 
// 閉じたセッションを開きなおす。
session_start();
// セッションIDを更新し、$_SESSION を古いセッションIDから切り離す。
session_regenerate_id();
// 新しいセッションID は有効期限なし。
unset($_SESSION[‘expire’]);
// ——————————————-
// セッションフィクセーション対策ここまで。
// あとは通常通り。
$_SESSION[‘user_id’] = “1234”;

 
また、session_regenerate_id() だけではセッション所有者のリクエストによる XSRF は防ぐことはできないため、こちら(開発者のための正しいCSRF対策)を参考にワンタイムトークン等も適宜組み合わせましょう。