三、sessionとcookieを理解する
4138 ワード
サーバはなぜ誰が要求しているのかを知る必要があります
httpリクエストは無状態であり、クライアントブラウザがリクエストをサービス側に送信し、サービス側がリクエストを処理して戻ってくると終了し、そのクライアントが再びサービス側をリクエストすると、同じユーザがアクセスしているかどうか分からない.例えば、ユーザは、ショッピングサイトで商品を選択してカートに加入し、注文して決済する.ユーザーが再びこのサイトにアクセスするには、自分のカートのデータ、注文書の商品のデータを取得する必要があります.
1回のセッションとは
ブラウザを使用して、ブラウザを閉じてセッションと呼ぶまで、どのくらいのリンクをクリックしても、どのくらいのページにアクセスしても、ブラウザを使用してWebサイトにアクセスします.
同じユーザが送信した複数のリクエストであるかどうかを識別する方法
ユーザーはブラウザを使用して初めてサービス側を要求し、サービス側が一意のidを生成し、このidをクライアントブラウザに送信し、その後、ユーザーがそのサイトで他のページにアクセスしたときにこのidをサーバに一括して送信することができれば、サーバはこれらの要求が同じid、すなわち同じユーザーから来たことを知らない.私たちはログインページを提供して、ユーザーはアカウント名、パスワードを入力してログインして、私たちはこのidをこのアカウント名に対応してサーバーファイルに保存して、ユーザーは更に要求を送って来た時にこのidを携帯して、サーバーはこのidを手に入れてファイルの中から探して、対応するユーザー名を見つけて、今回の要求がこのアカウントであることを知ることができます.
sessionとcookieがどのように協力して状態を維持するか【ログインを実現する】
sessionはサービス側が生成したこの唯一のidであり、サービス側ファイルに格納され、cookieはこのidを保存しており、ブラウザがサーバにアクセスするたびにこのidを携帯し、cookieはローカルコンピュータに格納されている.
ブラウザを使用して初めてウェブサイトにアクセスすると、サーバはidがないことを発見すると、一意のセッションidを生成し、サーバに格納し、同時にクッキーを書く命令を発行し、ユーザーブラウザはクッキーを書く命令を受信すると、ユーザーコンピュータの一時ディレクトリでクッキーファイルを生成し、キー名がPHPSESSIDであり、値がこのidである.後でこのサイトにアクセスすると、ブラウザは自動的にクッキーを携帯します.
【クッキーには有効期間があり、設定しないとセッションレベル、すなわちブラウザを閉じるというクッキーは無効になります】クッキーはユーザーのローカルコンピュータに格納されているため、セキュリティが悪く、パスワードなどの機密情報を格納することはできません.
セッションの有効期限は、通常、アクセスごとに現在の時間30分後に延長されます.そのため、ユーザーが長時間操作しないと期限が切れ、再ログインが要求され、サービス側seesion idもリフレッシュされ、クッキーを書くコマンドを発行してブラウザにid値の変更を要求します.
異なるサイトはブラウザにクッキーを書くように要求し、ブラウザはあるサイトにアクセスし、そのサイトのクッキーだけを携帯する.cookieはドメインの概念があって、もしドメインがなければ、ブラウザは銀行のウェブサイトに登録したcookieを私のウェブサイトに携帯することができて、私はこのcookieを持ってこの銀行のウェブサイトにアクセスすることができて、結果は登録状態で、お金を振り替えることができます.
Cookieは同じカーネルのブラウザ間で共有されており、異なるカーネルブラウザは共有されていない.例えば火狐やIE「格納場所が異なり、もちろん共有されていない」
セッションの期限切れの特別説明:
セッションの期限切れはぼんやりしている時間で、10分の期限切れを設定すると、9分でこのページを操作すると再カウントされます.
セッション構成:
セッションはphp.iniはsessionストレージの場所を変更するように構成され、デフォルトではファイル形式でサーバに格納され、userに設定するとプロセッサをカスタマイズしてsessionデータにアクセスできます.企業にはredisとデータベースが格納され、高同時性と負荷分散の複数のサーバ間セッション共有に対応します.
クッキーを無効にして、ログインできますか?
サーバ側で生成されたセッションidは、クッキーが無効になっていると、サーバから送信された書き込みクッキーコマンドがクライアントコンピュータのクッキーにセッションidを書き込むことができず、このサイトにアクセスするとクッキーを携帯することができず、セッションidを取得することもできない.重要な問題は、cookieが仲介者としてsession idをサーバに持ち込むことができず、ブラウザがそのサイトの他のページにアクセスする際にurlの後ろにPHPSESSID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxサーバ側で構成すればurl上で携帯する方法を設定します.
クッキーを無効にしてログインできますが、セッションを使用しなければログインできますか?
実際にクッキーやセッションを使用しないと、ステータスを維持したり、ログインしたりすることができます.クライアントがユーザ名、パスワードを入力すると、サービス側は検証を完了し、通過すると、トークン(一意乱数)が生成され、トークン対応ユーザがデータベース【mysqlやredisなど】でクライアント(ブラウザやappなど)に戻り、後でサーバにアクセスしてデータを取得する際に、このトークンを携帯し、サーバはトークンを取得すると,対応するユーザを知ることができ,そのユーザのデータを返す.トークンが期限切れにならない限り、ブラウザや携帯電話のappで取得したトークンも保持され、永遠にログイン状態になります.実際のエンタープライズ・プロジェクトでは、このトークンには期限切れがあります.たとえば、アクセスするたびにトークン時間を延長し、半月もアクセスしないと期限切れになり、要求データが暗号化されます.
ブラウザの7日間の自動ログインはどのように実現します
現象:
いくつかのWebサイトにログインして、終了をクリックするのではなくブラウザを直接閉じ、再びブラウザを開くとログイン状態になります.
理由:
クリックして退出するのは安全な退出と呼ばれて、実はクリックして退出して、サーバーのプログラムは私达がサービス端に保存したsessionの内容とidを破壊して、直接閉じるのはサーバー端sessionを削除していないで、cookieの期限切れの时间の设定は普通は比较的に长くて、ブラウザを闭じて、このウェブサイトにアクセスするcookieはまだ私达の地元のコンピュータの上で保存していますしたがって,ブラウザを開いて再度そのサイトにアクセスするとそのサイトのクッキーを携帯し,サーバ側にセッションidが存在し,アカウントにマッチングできるため,ログイン状態である.クッキーをセッションレベルに設定すると、ブラウザクッキーを閉じると期限切れになり、ブラウザを開いて再びアクセスしてもそのサイトクッキーが携帯されていないので、ログイン状態ではありません.そのため、7日間の自動ログインを実現するには、ローカルコンピュータのcookieが7日後に期限切れになり、サービス側のsession idも7日後に期限切れになると7日間の自動ログインを実現することができ、確かにsession idはデータベースなどに保存することができます.プロジェクトでは、このログインアカウントに対応するトークンを生成してデータベースに保存し、トークンをクッキーを書くことでユーザーのローカルコンピュータに保存し、ユーザーが再アクセスするときにこのトークンを携帯し、サーバはトークンで対応するアカウントを検索し、そのアカウント情報を取得します.例えば、サーバがユーザ名パスワードが通過したことを検証すると、トークンが生成され、トークンと対応するユーザ情報が暗号化されて暗号文が生成され、クッキー命令を書くことで明文トークンと暗号文がブラウザに返され、ローカルコンピュータに7日間保存される実装ロジックもある.ユーザが後でこのサイトにアクセスすると、ブラウザはcookie(明文トークンと暗号文)をサーバに持ち込み、サーバは暗号文中のユーザ情報とトークンを解読することによって取得し、暗号文中のトークンと明文トークンより検証を完了し、検証が通過すると、暗号文中のユーザ情報に基づいて現在のユーザアクセスセッションを生成し、サービスはトークン対応ユーザ情報を記憶する必要がなく、自動ログインが完了しました.張三自動登録サイトのクッキーを手に入れることができれば、登録を実現することができます.そのため、ユーザーが自動ログインオプションをチェックするときは、自分のパソコンを使って、公衆パソコンでこの機能を使用しないほうがいいです.
httpリクエストは無状態であり、クライアントブラウザがリクエストをサービス側に送信し、サービス側がリクエストを処理して戻ってくると終了し、そのクライアントが再びサービス側をリクエストすると、同じユーザがアクセスしているかどうか分からない.例えば、ユーザは、ショッピングサイトで商品を選択してカートに加入し、注文して決済する.ユーザーが再びこのサイトにアクセスするには、自分のカートのデータ、注文書の商品のデータを取得する必要があります.
1回のセッションとは
ブラウザを使用して、ブラウザを閉じてセッションと呼ぶまで、どのくらいのリンクをクリックしても、どのくらいのページにアクセスしても、ブラウザを使用してWebサイトにアクセスします.
同じユーザが送信した複数のリクエストであるかどうかを識別する方法
ユーザーはブラウザを使用して初めてサービス側を要求し、サービス側が一意のidを生成し、このidをクライアントブラウザに送信し、その後、ユーザーがそのサイトで他のページにアクセスしたときにこのidをサーバに一括して送信することができれば、サーバはこれらの要求が同じid、すなわち同じユーザーから来たことを知らない.私たちはログインページを提供して、ユーザーはアカウント名、パスワードを入力してログインして、私たちはこのidをこのアカウント名に対応してサーバーファイルに保存して、ユーザーは更に要求を送って来た時にこのidを携帯して、サーバーはこのidを手に入れてファイルの中から探して、対応するユーザー名を見つけて、今回の要求がこのアカウントであることを知ることができます.
sessionとcookieがどのように協力して状態を維持するか【ログインを実現する】
sessionはサービス側が生成したこの唯一のidであり、サービス側ファイルに格納され、cookieはこのidを保存しており、ブラウザがサーバにアクセスするたびにこのidを携帯し、cookieはローカルコンピュータに格納されている.
ブラウザを使用して初めてウェブサイトにアクセスすると、サーバはidがないことを発見すると、一意のセッションidを生成し、サーバに格納し、同時にクッキーを書く命令を発行し、ユーザーブラウザはクッキーを書く命令を受信すると、ユーザーコンピュータの一時ディレクトリでクッキーファイルを生成し、キー名がPHPSESSIDであり、値がこのidである.後でこのサイトにアクセスすると、ブラウザは自動的にクッキーを携帯します.
【クッキーには有効期間があり、設定しないとセッションレベル、すなわちブラウザを閉じるというクッキーは無効になります】クッキーはユーザーのローカルコンピュータに格納されているため、セキュリティが悪く、パスワードなどの機密情報を格納することはできません.
セッションの有効期限は、通常、アクセスごとに現在の時間30分後に延長されます.そのため、ユーザーが長時間操作しないと期限が切れ、再ログインが要求され、サービス側seesion idもリフレッシュされ、クッキーを書くコマンドを発行してブラウザにid値の変更を要求します.
異なるサイトはブラウザにクッキーを書くように要求し、ブラウザはあるサイトにアクセスし、そのサイトのクッキーだけを携帯する.cookieはドメインの概念があって、もしドメインがなければ、ブラウザは銀行のウェブサイトに登録したcookieを私のウェブサイトに携帯することができて、私はこのcookieを持ってこの銀行のウェブサイトにアクセスすることができて、結果は登録状態で、お金を振り替えることができます.
Cookieは同じカーネルのブラウザ間で共有されており、異なるカーネルブラウザは共有されていない.例えば火狐やIE「格納場所が異なり、もちろん共有されていない」
セッションの期限切れの特別説明:
セッションの期限切れはぼんやりしている時間で、10分の期限切れを設定すると、9分でこのページを操作すると再カウントされます.
セッション構成:
セッションはphp.iniはsessionストレージの場所を変更するように構成され、デフォルトではファイル形式でサーバに格納され、userに設定するとプロセッサをカスタマイズしてsessionデータにアクセスできます.企業にはredisとデータベースが格納され、高同時性と負荷分散の複数のサーバ間セッション共有に対応します.
vi /usr/local/etc/php/7.2/php.ini
session.save_handler = files
クッキーを無効にして、ログインできますか?
サーバ側で生成されたセッションidは、クッキーが無効になっていると、サーバから送信された書き込みクッキーコマンドがクライアントコンピュータのクッキーにセッションidを書き込むことができず、このサイトにアクセスするとクッキーを携帯することができず、セッションidを取得することもできない.重要な問題は、cookieが仲介者としてsession idをサーバに持ち込むことができず、ブラウザがそのサイトの他のページにアクセスする際にurlの後ろにPHPSESSID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxサーバ側で構成すればurl上で携帯する方法を設定します.
クッキーを無効にしてログインできますが、セッションを使用しなければログインできますか?
実際にクッキーやセッションを使用しないと、ステータスを維持したり、ログインしたりすることができます.クライアントがユーザ名、パスワードを入力すると、サービス側は検証を完了し、通過すると、トークン(一意乱数)が生成され、トークン対応ユーザがデータベース【mysqlやredisなど】でクライアント(ブラウザやappなど)に戻り、後でサーバにアクセスしてデータを取得する際に、このトークンを携帯し、サーバはトークンを取得すると,対応するユーザを知ることができ,そのユーザのデータを返す.トークンが期限切れにならない限り、ブラウザや携帯電話のappで取得したトークンも保持され、永遠にログイン状態になります.実際のエンタープライズ・プロジェクトでは、このトークンには期限切れがあります.たとえば、アクセスするたびにトークン時間を延長し、半月もアクセスしないと期限切れになり、要求データが暗号化されます.
ブラウザの7日間の自動ログインはどのように実現します
現象:
いくつかのWebサイトにログインして、終了をクリックするのではなくブラウザを直接閉じ、再びブラウザを開くとログイン状態になります.
理由:
クリックして退出するのは安全な退出と呼ばれて、実はクリックして退出して、サーバーのプログラムは私达がサービス端に保存したsessionの内容とidを破壊して、直接閉じるのはサーバー端sessionを削除していないで、cookieの期限切れの时间の设定は普通は比较的に长くて、ブラウザを闭じて、このウェブサイトにアクセスするcookieはまだ私达の地元のコンピュータの上で保存していますしたがって,ブラウザを開いて再度そのサイトにアクセスするとそのサイトのクッキーを携帯し,サーバ側にセッションidが存在し,アカウントにマッチングできるため,ログイン状態である.クッキーをセッションレベルに設定すると、ブラウザクッキーを閉じると期限切れになり、ブラウザを開いて再びアクセスしてもそのサイトクッキーが携帯されていないので、ログイン状態ではありません.そのため、7日間の自動ログインを実現するには、ローカルコンピュータのcookieが7日後に期限切れになり、サービス側のsession idも7日後に期限切れになると7日間の自動ログインを実現することができ、確かにsession idはデータベースなどに保存することができます.プロジェクトでは、このログインアカウントに対応するトークンを生成してデータベースに保存し、トークンをクッキーを書くことでユーザーのローカルコンピュータに保存し、ユーザーが再アクセスするときにこのトークンを携帯し、サーバはトークンで対応するアカウントを検索し、そのアカウント情報を取得します.例えば、サーバがユーザ名パスワードが通過したことを検証すると、トークンが生成され、トークンと対応するユーザ情報が暗号化されて暗号文が生成され、クッキー命令を書くことで明文トークンと暗号文がブラウザに返され、ローカルコンピュータに7日間保存される実装ロジックもある.ユーザが後でこのサイトにアクセスすると、ブラウザはcookie(明文トークンと暗号文)をサーバに持ち込み、サーバは暗号文中のユーザ情報とトークンを解読することによって取得し、暗号文中のトークンと明文トークンより検証を完了し、検証が通過すると、暗号文中のユーザ情報に基づいて現在のユーザアクセスセッションを生成し、サービスはトークン対応ユーザ情報を記憶する必要がなく、自動ログインが完了しました.張三自動登録サイトのクッキーを手に入れることができれば、登録を実現することができます.そのため、ユーザーが自動ログインオプションをチェックするときは、自分のパソコンを使って、公衆パソコンでこの機能を使用しないほうがいいです.