セッションにカウンター変数があるかどうかを確認し、ない場合は、値0で作成してから、その値を表示して1つ増やします。 増加した値はセッションに書き込まれ、次にスクリプトが呼び出されたときに、変数の値は1になり、以下同様に続きます。 すべてがとてもシンプルです。

サイトの任意のページのセッション変数にアクセスするには、セッションが必要なすべてのファイルの先頭に1行だけ（！）を書き込む必要があります。

session_start（）;

session_start（）;
if（$ _SESSION ["authorized"]<> 1 ) {
header（ "場所：/auth.php"）;
出口;
}

セッションから変数を削除します。 register_globals = offがある場合は、次のように書くだけで十分です。

unset（$ _ SESSION ["var"]）;

そうでない場合は、 近くそれであなたは書く必要があります：

session_unregister（ "var"）;

どのセッションを使用すべきか、何を使用すべきでないかを理解することは非常に重要です。

まず、セッションはユーザーが必要とする場合にのみ使用でき、ユーザーの邪魔にならないことを忘れないでください。 結局のところ、彼はいつでも識別子を取り除くことができます！
たとえば、スクリプトではなくフォームに入力していることを確認するときに、ユーザー自身がセッションを機能させることに関心があるとします。そうしないと、フォームを送信できなくなります。 ただし、スクリプトへのリクエスト数を制限するために、セッションは適切ではなくなりました。悪意のあるスクリプトは単に識別子を返しません。

第二に。 人が理解しているように、セッションがサイトでの作業のセッションであるという事実を明確に理解することが重要です。 来て、働いて、ブラウザを閉じました-セッションは終了しました。 映画のセッションのように。 別のチケットを見たい場合は、新しいチケットを購入してください。 新しいセッションを開始します。 これについての技術的な説明もあります。 セッションメカニズムは、ブラウザが閉じられるまでのみ機能することが保証されています。 結局のところ、Cookieはクライアントに対して機能しない可能性があり、この場合、もちろん、識別子が追加されたすべてのリンクは、閉じられると消えます。

確かに、ブラウザを閉じないとセッションが消えることがあります。 この記事で説明した制限により、セッションメカニズムでは、ユーザーがいつブラウザを閉じたかを判断できません。 このために、タイムアウトが使用されます。これは、ユーザーがサイトを離れたと見なされる所定の時間です。 デフォルトでは、この設定は24分です。

ユーザー情報を長期間保存する場合は、Cookieを使用し、必要に応じてサーバー上のデータベースを使用します。 特に、これはすべての一般的な認証システムの仕組みです。

ユーザーが識別されると、セッションが開始され、認証のサインがセッションで送信されます。
-ユーザーを「記憶」する必要がある場合、ユーザーを識別するCookieが配置されます。
-ユーザーが次にサイトにアクセスするときにログインするには、パスワードを入力する必要があります。そうしないと、システム自体が以前に設定されたCookieによってユーザーを認識し、セッションが開始されます。 古いセッションを継続するのではなく、新しいセッション。

第三に、サイトに入るすべての人のために、無差別にセッションを開始するべきではありません。 これは完全に不必要な負担を生み出します。 ささいなことのためにセッションを使用しないでください-たとえば、カウンターで。 もちろん、スパイログがセッションと呼ぶものは、ヒット統計に基づいて計算され、PHPのようなセッションメカニズムを使用していません。

さらに、あなたのサイトにインデックスを付ける検索エンジンを見てみましょう。 検索ロボットがCookieをサポートしていない場合、デフォルトでPHPはリンクにPHPSESSIDを提供します。これは、検索エンジンではあまり人気がない可能性があります。これは、噂によると、動的リンクを優先しませんが、ここでは一般的に、訪問するたびに-新しいアドレス！

セッションを使用してサイトのプライベートセクションへのアクセスを制限する場合、すべてが単なる検索エンジンであり、インデックスを作成するべきではありません。 承認されたユーザーと承認されていないユーザーの両方に同じページを表示する必要がある場合は、このトリックが役立ちます。パスワードを入力したユーザー、またはすでにセッションを開始しているユーザーに対してのみセッションを開始します。

これを行うには、単にではなく、各ページの上部に session_start（）私たちは書く：

if（isset（$ _ REQUEST [session_name（）]））session_start（）;

したがって、識別子を送信した人に対してのみセッションを開始します。
したがって、承認時に初めてユーザーに送信する必要があります。

名前とprolが正しければ、次のように記述します。 session_start（） !

セッションを操作しようとしたときにPHPがスローする最も一般的なエラーは次のとおりです。
それらのうちの2つ

警告：セッションCookieを送信できません-ヘッダーはすでに送信されています
警告：セッションキャッシュリミッターを送信できません-ヘッダーはすでに送信されています

同じ理由で引き起こされ、解決策はこの偽物で説明されています

警告：open（/ tmp \ sess_SID、O_RDWR）が失敗しました：行番号のfull_script_pathにそのようなファイルまたはディレクトリ（2）がありません

彼女が見える前に

警告：セッションデータ（ファイル）の書き込みに失敗しました。 session.save_pathの現在の設定が正しいことを確認してください（/ tmp） ,

英語から翻訳すると、問題が詳細に説明されます。php.iniで指定されたディレクトリへのパスが利用できず、セッションファイルが書き込まれます。 このエラーは最も簡単に修正できます。 たとえば、存在して書き込み可能なディレクトリを作成するだけです。

session.save_path = c：\ windows \ temp

その後、Apacheを再起動することを忘れないでください。

結局のところ、人間の創意工夫には限界がないので、私は次のことを説明せざるを得ません。
3番目のエラーメッセージ（ディレクトリが見つかりません）は、最初の2つに必然的になります。これは、エラーメッセージがブラウザに出力され、その後はヘッダーを使用できないためです。 したがって、時期尚早の結論を急いで探すのではなく、最初に正しい道を書き留めてください！

セッションに関する次の最も一般的な問題は、register_globalsの大きな遺産です。 $ _SESSION配列のインデックスと一致するスクリプト変数名を付けないでください。

register_globals = onを指定すると、値が互いに上書きされ、混乱します。

それが機能しないがメッセージが表示されない場合は、画面にすべてのエラーを表示する責任があるスクリプトの最初に2行を追加します-エラーがある可能性は十分にありますが、単にそれらが表示されません。

ini_set（ "display_errors"、1）;
error_reporting（E_ALL）;

または、error_logのエラーを参照してください。 一般に、エラーメッセージの表示に関するトピックはこの記事の範囲を超えているため、少なくともエラーメッセージが表示されることを確認してください。 このセクションで、エラーの検出についてもう少し読むことができます。

エラーがないことは確かですが、上記の例がとにかく機能しない場合は、PHPがURLを介したIDの受け渡しを有効にしていない可能性があります。 とクッキーは何らかの理由で機能しません.
あなたがクッキーで持っているものを見てください。

一般に、セッションが機能しない場合は、最初にセッションIDを手動で渡すか、リンクを作成してIDを割り当てます。

これを行うときは、session.use_only_cookiesディレクティブが含まれていないことを確認してください。これにより、PHPがURLを介して渡された場合にセッションIDを受け入れることができなくなります。

この例が機能しない場合、問題は平凡なものにあります ミスプリント（セッションの「問題」の半分は、スペルミスのある変数名に起因します）、または古すぎるバージョンのPHP：セッションサポートはバージョン4.0で導入され、配列 $ _SESSION-4.1で（以前に使用された $ HTTP_SESSION_VARS).

それが機能する場合、問題はCookieにあります。 追跡-ブラウザがブラウザに返すかどうかにかかわらず、サーバーがブラウザにどのような種類のCookieを配置するか。 検索は、ブラウザとサーバー間のHTTPヘッダーの交換を調べることで非常に役立ちます。

Cookieがどのように機能するかについての説明は、このすでに長すぎるテキストの範囲を超えていますが、少なくともサーバーが識別子を使用してCookieを送信し、ブラウザーがCookieを返すことを確認してください。 同時に、識別子は互いに一致します=）
Cookieの設定は次のようになります

Set-Cookie：PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6;

Set-Cookie：PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6; パス= /

（ルートディレクトリからではなくスクリプトを要求している場合）
サーバーの応答は次のようになります

クッキー：PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6

クッキー：PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6; b = b

ブラウザがセッションID以外のCookieを返した場合。

ここの例が機能するが、独自のコードが機能しない場合、問題は明らかにセッションではなく、アルゴリズムにあります。 変数を失った場所を探し、ここから例を段階的に転送し、スクリプトをデバッグします。

したがって、たとえば次のように、識別子を手動で追加する必要があります。

header（ "Location：/script.php？" .session_name（）。 "=" .session_id（））;

また、非常にまれであり、それがどこから来ているのかが完全に不明です。問題は、session.save_handler設定にファイル以外の値があることです。 そうでない場合は、修正してください。

• Cookieに加えて、セッションメカニズムは、ページキャッシュを禁止するヘッダー（同じキャッシュリミッター）も送信します。 HTMLの場合、これは正しく、必要です。 ただし、認証を確認するスクリプトを使用してファイルを送信しようとすると、InternetExplorerはそのファイルのダウンロードを拒否します。 このタイトルのせいです。 電話
  session_cache_limiter（ "private"）;
  セッションを開始する前に、問題を解決する必要があります。
• 奇妙に見えるかもしれませんが、配列内 $ _SESSION数値インデックスは使用できません- $ _SESSION [1]、$ _ SESSION ["10"]-セッションは機能しません。
• バージョン4.2と5.0の間のどこかで、session.use_trans_sidを設定することができませんでした ini_set（）。 5.0から、それはすでに再び可能です。
• バージョン4.3.3以前のCookieは、セッションの開始時にリクエストに識別子が含まれていなかった場合にのみCookieを送信していました。 これで、すべての呼び出しでCookieが送信されます session_start
  
  

  さらに質問がある場合、または何かが明確でない場合は、私たちへようこそ

セッションは、一意のセッションIDを持つ個々のユーザーの情報を保存する簡単な方法です。 これは、ページ要求間の状態を保存するために使用できます。 セッションIDは通常、セッションCookieを介してブラウザに送信され、使用可能なセッションデータを取得するために使用されます。 セッションIDまたはセッションCookieがない場合、PHPは新しいセッションを作成して新しいセッションIDを生成するように指示されます。

セッションは単純なテクノロジーを使用します。 セッションが作成されると、PHPは渡されたID（通常はセッションCookieから）を使用して既存のセッションを取得するか、何も渡されなかった場合は新しいセッションが作成されます。 PHPは、セッションの開始後に$ _SESSIONスーパーグローバルにセッション情報を入力します。 PHPが終了すると、$ _ SESSIONスーパーグローバルの内容が自動的にシリアル化され、セッションハンドラーを使用して永続性に送信されてセッションが記録されます。

デフォルトでは、PHPは内部ファイルハンドラーを使用してセッションを保存します。これは、INI変数session.save_handlerで設定されます。 このハンドラーは、サーバー上のsession.save_path構成ディレクティブで指定されたディレクトリーにデータを保存します。

機能を使用して手動でセッションを開始できます session_start（）。 session.auto_startディレクティブが1に設定されている場合、セッションはリクエストの開始時に自動的に開始されます。

通常、セッションはPHPがスクリプトの実行を終了すると終了しますが、関数を使用して手動で終了することもできます。 session_write_close（）.

警告

注意

コメント:

ファイルを使用するセッション（PHPのデフォルト）は、関数によってセッションが開かれるとすぐにセッションファイルをロックします session_start（）または、session.auto_startを指定して間接的に。 ロックされると、スクリプトが終了するか関数が呼び出されるときに閉じられるまで、他のスクリプトは同じセッションファイルにアクセスできません。 session_write_close（）.

これは、AJAXを多用し、複数の同時リクエストを行うサイトでは問題になる可能性があります。 この問題を解決する最も簡単な方法は、関数を呼び出すことです session_write_close（）セッションで必要なすべての変更が行われるとすぐに、できればスクリプトの開始に近づきます。 同時アクセスをサポートする別のセッションメカニズムを使用することもできます。

当初からPHPは大成功で受け入れられましたが、この言語で十分な規模のプロジェクトが作成されるとすぐに、開発者は新しい問題に直面しました。PHPにはグローバル変数の概念がありませんでした。 つまり、特定のスクリプトが実行され、生成されたページがクライアントに送信され、このスクリプトで使用されていたすべてのリソースが破棄されました。 説明してみましょう。同じサイトにindex.phpとdothings.phpの2つのページがあるとします。 これらのページのソースコードは次のようになります。

これらの2つのスクリプトを実行すると、最初のページに「index.phpを要求されました」という碑文が表示され、2番目のページは空になります。

Webサイトの開発者は、よく考えずに、Cookieを使用してクライアント側にグローバル変数を格納し始めました。 プロセスは次のようになりました。ユーザーがサイトのメインページにアクセスし、いくつかのアクションを実行すると、サイトの他のページで必要になる可能性のあるこのユーザーに関連するすべての情報が、次の形式でブラウザに保存されます。クッキーの。 この方法には非常に深刻な欠点があります。そのため、多くの開発者が一度にPHPに背を向けました。 たとえば、ユーザーがサイトのプライベートセクション（またはユーザーのみが所有するセクション）にアクセスできるようにする必要があります。 ユーザーにCookieを送信する必要があります。これは、サイトでの後続の識別子として機能します。 このアプローチは、サイトがユーザーの行動に関する情報を収集し始めるとすぐに非常に面倒で不便になります。これは、ユーザーに送信されたすべての情報を偽造できないようにエンコードすることが望ましいためです。 最近では、偽のCookieが複数のチャットを「置く」可能性があり、場合によっては他の誰かのメールに侵入することさえあります。 さらに、ブラウザがCookieをサポートしていない奇妙な人々が世界にまだいます。

セッションメカニズムの技術的な問題については説明しませんが、PHPでセッションを適切に操作する方法についてのみ説明します。

セッションを操作する方法は？

いくつかの商用ホスティングで記​​事（またはスクリプト）の例をテストする場合、セッションの操作に問題はないはずです。 サーバーを自分でセットアップした場合（実サーバーであろうとエミュレーターであろうと）、次のようなエラーが表示される場合があります。

「警告：open（/ var / state / php / sess_6f71d1dbb52fa88481e752af7f384db0、O_RDWR）が失敗しました：そのようなファイルまたはディレクトリはありません（2）」。

これは、PHPが正しく構成されていないことを意味します。 この問題は、セッションをphp.iniファイルに保存してサーバーを再起動するための正しいパス（既存のディレクトリへの）を設定することで解決できます。

セッションからの変数（データ）を使用するスクリプトには、次の行が含まれている必要があります。

session_start（）;

このコマンドは、このページにこのユーザー（ブラウザー）に関連付けられているすべての変数が必要であることをサーバーに通知します。 サーバーはこれらの変数をファイルから取得し、使用可能にします。 データがユーザーに送信される前にセッションを開くことが非常に重要です。 実際には、これは、次のように、ページの最初でsession_start（）関数を呼び出すことが望ましいことを意味します。

session_start（）; ？> ...セッションファイルを保存するディレクトリを設定するには、session_save_path（）関数を使用します。session_save_path（$ _ SERVER ["DOCUMENT_ROOT"]。 "/ session"）; session_start（）;

セッションが開始されると、グローバル変数を設定できます。 $ _SESSION配列の任意のフィールドに値を割り当てると、同じ名前の変数がセッション変数として自動的に登録されます。 この配列は、セッションを使用するすべてのページで使用できます。 例としてプログラムを取り上げましょう。

これらのファイルを順番に実行すると、最初の「index.php」スクリプトは次の結果を生成します。

そして2番目の「dothings.php」はこれです：

$ a変数は、セッションを開始したこのサイトのすべてのページで使用できるようになりました。

セッションを操作するためのその他の便利な機能とコツ：

• unset（$ _ SESSION ["a"]）-セッションは、指定されたセッション変数の値を「忘れる」。
• session_destroy（）-セッションが破棄されます（たとえば、ユーザーが「ログアウト」ボタンを押してシステムを離れた場合）。
• session_set_cookie_params（int Lifetime [、string path [、string domain]]）-この関数を使用すると、セッションの「終了」時刻を決定するunix_timestampを設定することにより、セッションが「存続」する期間を設定できます。 デフォルトでは、セッションはクライアントがブラウザウィンドウを閉じるまで存続します。
• session_write_close（）-セッション変数を記録して閉じます。 これは、ページの処理に時間がかかり、ブラウザのセッションファイルがブロックされている場合に、新しいウィンドウでサイトを開くために必要です。

例

それでは、セッションメカニズムの実際のアプリケーションに移りましょう。 ここでは、かなり単純でありながら有用な例をいくつか見ていきます。

ユーザー認証

PHPセッションを使用したユーザー認証に関する質問は、Webプログラミング会議で常に尋ねられます。 セッションを使用してシステム内のユーザーを承認するためのメカニズムは、セキュリティの観点から非常に優れています（セクションを参照）。

この例は、index.php、authorize.php、secretplace.phpの3つのファイルで構成されます。 index.phpファイルには、ユーザーがユーザー名とパスワードを入力するフォームが含まれています。 このフォームはデータをauthorize.phpファイルに渡します。これにより、承認が成功した場合にユーザーがsecretplace.phpファイルにアクセスできるようになります。そうでない場合は、エラーメッセージが表示されます。

例： index.php

安全性

したがって、あるページ（PHPスクリプト）から別のページ（サイトからの次の呼び出しまで）に識別子を渡すことができます。これは、すべてのサイト訪問者を区別できることを意味します。 セッション識別子は非常に大きな数（128ビット）であるため、ブルートフォースでそれを取得できる可能性はほとんどありません。 したがって、攻撃者には次のオプションが残されます。

• ユーザーのコンピューターには、セッション番号を盗む「トロイの木馬」があります。
• 攻撃者は、ユーザーのコンピューターとサーバー間のトラフィックをキャプチャします。 もちろん、安全な（暗号化された）SSLプロトコルがありますが、誰もがそれを使用しているわけではありません。
• 隣人がユーザーのコンピューターに近づき、セッション番号を盗みました。

誰かが誰かから何かを盗むという事実に基づくそのような状況は、一般に、プログラマーの能力の範囲内ではありません。 管理者とユーザー自身がこれを処理する必要があります。

ただし、PHPは非常に頻繁に「だまされる」可能性があります。 ユーザー認証プログラムで発生する可能性のあるハッキングを見てみましょう。

• authorize.phpファイルは、サードパーティのスクリプトを使用してパスワードを推測する試みです。
• ファイルsecretplace.phpは、次のように、ブラウザのアドレスバーに$ logged_user変数の値を入力してプログラムをだまそうとします。
  「http://www.yoursite.ru/secretplace.php？ Logged_user = hacker"

したがって、私たちのプログラムでは、2つの「穴」がはっきりと見えます。1つは小さくてあまり目立たないものですが、2つ目は巨大で、ほとんどのハッカーは必要のない場所に登ります。

IPアドレスなどをブロックするための大量のコードを記述するのではなく、リクエストがどこから来たのか、つまり、リクエストがどのページから来たのかを確認するだけです。サイトのページであれば、すべて問題ありません。しかし、他のすべての場合、私たちは許可しません。 authorize.phpファイルを修正しましょう。

すべての定命の者がフォーラムに投稿するために登録できるWebサイトがあるとします。 当然、フォーラムでは、一部のユーザー（管理者、モデレーター）が他のユーザーよりも多くの機会を持っています。たとえば、他のユーザーからのメッセージを削除できます。 ユーザーのアクセスレベルをセッションの$ user_status変数に格納します。ここで、$ user_status = 10は完全なシステムアクセスに対応します。 サイトにアクセスした攻撃者は、通常の方法で登録し、ブラウザのアドレスバーに追加するだけで十分です。 ？user_status = 10。 だからあなたはフォーラムに新しい管理者を迎えました！

原則として、スクリプトの完全なアドレスの後に疑問符を追加し、変数の名前とその値を追加するだけで、アドレスバーを介して任意のスクリプト変数を設定できます。 これを回避するためにコードを修正しましょう：

セッションメカニズムは、PHP言語の非常に優れた機能です。 セッションはシンプルで、非常に柔軟に使用できます。 ちなみに、PHPセッションには文書化された機能が1つあります（バージョン4.0.3以降で利用可能）-セッションは変数だけでなくオブジェクトも格納できます。

例

カウンター

カウンター