スマートフォンでクッキーが使えるようなので、スマートフォンおよびPCを対象にして携帯を無視した会員サイトが増えてくるでしょう。

ではではセッション管理をクッキーのみに限定したログイン認証およびそれ以降の簡単な処理分けを書いてみます。


<?php

// ページ定義
define('PAGE_A'     , 'a'     );
define('PAGE_B'     , 'b'     );
define('PAGE_C'     , 'c'     );
define('PAGE_LOGOUT', 'logout');
define('PAGE_AUTH'  , 'auth'  );

// 認証を通過した証のためのキー名定義
define('USER_LOGIN_NOW', '_user_login_now_');


// セッション開始前の設定
ini_set('session.use_cookies'     , 1     );   // クッキーを使います
ini_set('session.name'            , 'skey');   // セッションのキー名を独自指定
ini_set('session.use_trans_sid'   , 0     );   // リクエストパラメータに自動付加しない
ini_set('session.use_only_cookies', 1     );   // クッキーからのskeyのみを使います


// セッション開始
session_start();
// セッションハイジャック対策
session_regenerate_id(true);  // PHP5.1.0から




switch ($_POST['action']) {

case PAGE_A:      // ページAに遷移
    if (empty($_SESSION[USER_LOGIN_NOW])) loginForm(); // 証が無ければ差し戻し
    a();
    break;
case PAGE_B:      // ページBに遷移
    if (empty($_SESSION[USER_LOGIN_NOW])) loginForm();
    b();
    break;
case PAGE_C:      // ページCに遷移
    if (empty($_SESSION[USER_LOGIN_NOW])) loginForm();
    c();
    break;
case PAGE_LOGOUT: // ログアウトなら
    if (empty($_SESSION[USER_LOGIN_NOW])) loginForm();
    logout();
    break;
caes PAGE_AUTH:   // ログイン情報の送信があれば
    auth();
    break;
default:          // デフォルトはすべてログイン画面へ
    loginForm();
    break;

}


// 認証を行い、結果に応じて画面遷移させる
function auth() {

    // データベースなどの内部データと一致するか検証
    if ($_POST['ID'] === ユーザID && $_POST['PASS'] === パスワード) {

        $_SESSION[USER_LOGIN_NOW] = ユーザID; // 認証を通過した証
        a();         // ログイン直後に表示させたいページへ
    } else {

        loginForm(); // 差し戻し
    }
}
function logout() {

    $_SESSION = array();
    session_destroy();
    header("Location: http://www.example.com/");
    exit;
}

// 以下省略
function loginForm() { echo "<form>~</form>"; exit; }
function a() { ... }
function b() { ... }
function c() { ... }


セッション中はいつでもログインしてるユーザIDを取得できるように例えばUSER_LOGIN_NOWというスペシャルなキーを定義した定数を使いまわすと便利だと思います。
大事なのは、ログインが完了した時点で1度だけこれをセットすることです。

もし完了前にセットしてしまうと、認証を通過してないのにログインが完了した証のセッション変数値を持つことになってしまいます。
その状態で然るべきaction値がPOST送信されてきたらもうお手上げです。


以上を気を付ければ不正なaction値が来てもすべてログイン画面へ差し戻すことができると思います。
セッションの基本であり骨格部分なのでシンプルに書いてみました。


あとはセッション開始前にsession_save_pathを指定するとか共有サーバの場合は必要かも知れません。

その他のテクニックとして、セッションファイルのロックを短時間で開放させるためにセッション変数($_SESSION)でのやり取りが完了した後は早めにsession_write_close()しておくなどは使えそうなテクニックだと思います。

<pre>タグ使って字下げしたけど、はみ出した部分の表示が隠蔽されてイマイチだけど面倒だからとりあえずこれで

私は携帯電話はおろか、最近よく耳にする「スマートフォン」についてまったく知らなかったのでちょいと調べてみました。
というか、携帯電話とスマートフォンが同一なのか別物なのかさえも今の今まで知らなかったほどです。
なので間違いとか平気で書いてしまう恐れがあります。



まず見た目の特徴として、スマートフォンにはボタン類が無いようです。画面も携帯よりちょいデカそう。
携帯電話にボタンがいっぱい付いてる程度は私も知っていたのでこれは意外ですね。



このような特徴からスマートフォンと呼ばれているものには以下のものがあるようです。


・iPhone
・Android
・Windows Mobile



ボタン類が無いというのは外観的な特徴ですが、内部的な特徴としては「搭載されているOS アプリケーションがカスタマイズできる」らしいです。
つまり特定の機能を使いたくば、OS上に専用のアプリケーションをダウンロードしてきて、インストールして使うがよい グァハハハ
みたいなノリでしょうかね。。。



なので電話でさえも、その通話機能を使いたかったら専用アプリケーションをインストールすべきという感じでしょうかね。
もちろん電話番号の契約とかも必要でしょうけど


ボタン類が無いので専用アプリケーションを使って、銀行のATMみたいなタッチパネルに表示された番号を押すみたいな使い方をするんでしょうね。



あと驚いたことに、HTMLやCSSに関してPCで使ってるブラウザと同程度の表示ができるようです。
しかもクッキーが使えるのでそれでセッション管理が可能なことと、JavaScriptも使えるということらしいです。
それからHTML5にも対応してるらしいのでいろいろな表現ができてもうflashは役目が終わったとの声も??


まぁそれも専用アプリケーションが対応してくれてればこそでしょうけど。



つまりスマートフォンは携帯サイト表示よりもPCサイト表示向けなわけですね。
このことから複雑な携帯サイト構築の時代はサクッと終わりが近そうですな。


今日の昼は3食やきそばの最後の1つが賞味期限ぎりぎりになって残っていたのでそれを食ったのさ。


私の場合は、麺を投入する前から勝負は始まっている。


とにかくフライパンが温まるまでに麺をいい感じにほぐしておくのさ。
そうすると麺投入した段階で既にほぐす作業が不要になるわけね。



ところが賞味期限ぎりぎりともなるとそう一筋縄ではいかない。

やはり麺の含む水分量が減っていて、下手なほぐし方したらブツブツと切れてしまう。


このチカラ加減の絶妙さを未だに研究中だったりする。



にしてもやきそばがなぜ3食入りなのかはかなり研究された結果なんだろうなと思う。


だいたい2週間? 程度ある賞味期限内において、

人間たる者、3度ぐらいはやきそば食べるっしょ!!


みたいな緻密な計算を微分積分あるいはサインコサインとか使って割り出してるに違いない。