クッキー和セッション

クッキーとセッションWeb開発この記事では、原則として、どのように行くの言語クッキーで動作するように記述の一部の周りに開いて、クッキーセッションされていません。

クッキーの起源

HTTPプロトコルはステートレスで、問題があります。

ステートレスは、直接バックに影響を及ぼさない、それは直接応答に影響を与える、前述の要求によって限定されるものではなく、各要求は、その実行と以前の要求と後続の要求の結果は直接関係しない、独立であることを意味します要求応答状況。

人生を記述するために、興味深い言葉だけでストライキとして、サーバーのため、各要求が新規です。

状態データは、特定のセッションで作成したクライアントとサーバとして理解することができ、そして何の状態は、これらのデータは保持されないことを考えていないしていること。生成されたセッションデータは、我々は保存する必要があり、それはにある「ホールド。」だから、クッキーは、このようなシナリオの下に生まれています。

クッキーとは何ですか

インターネット上では、クッキーは、実際には、Webサーバー、ユーザーのコンピュータ（クライアント）に格納されたデータファイルの情報によって作成され、少量の情報を指します。一般的なネットワークのユーザーは、クッキーの複数形を使用することに慣れているユーザのローカル端末ストレージ上のユーザーID、セッションの追跡とデータを識別するために、特定のサイトを参照し、これらのデータは、通常は暗号化されています。

クッキーメカニズム

クッキーは、サーバによって生成されたUser-Agent（通常はブラウザ）に送信され、ブラウザがキー/値のクッキーがディレクトリ内のテキストファイルに保存されます、それはクッキーにリクエストを送信し、同じサイトの横サーバー（ブラウザはクッキーを有効にするために設定されている場合）。サーバは、ユーザが正当なユーザと再サインオンする必要があるかどうかを知ることができるように、クッキーの名前と値は、サーバの独自の定義によって開発されてもよく、それによってサーバのセッションにユーザの状態を維持し、クッキーに含まれる情報を設定するか、読み取ることができるサーバ。

クッキーの機能を要約すると：

ブラウザが以前に保存されたに自動的にCookie情報を要求を送信すると、サイトを運びます。
Cookieのデータ・サーバを設定することができます。
クッキーは、異なるドメイン間でのCookieが独立している、単一のドメイン名のためです。
クッキーのデータは、有効期限を設定することができますクッキーデータがシステムにクリアされます期限切れ。

ビューのクッキー

私たちは、コンピュータに保存されているサイトのCookieデータを表示するために、オープンな開発ツールをWebサイトを開くには、Chromeブラウザを使用します。

操作クッキーを行きます

標準ライブラリは、net/httpクッキーが発生HTTPリクエスト又はHTTPレスポンスヘッダでSet-Cookieヘッダの値を表すクッキーを、定義されましたHTTP cookie。

クッキー型のstruct { 
    名前        の文字列
    値       文字列
    のパス        文字列
    のドメイン      文字列
    time.time有効期限
    RawExpires 文字列
    // MaxAgeの= 0は、属性がMaxAgeの設定されていないことを示し
     // MaxAgeの<0がMaxAgeの「に相当し、すぐにクッキーを削除して示しています0 「
     // MaxAgeの> 0秒で、プレゼンスMaxAgeの特性を示し 
    MAXAGE    int型
    セキュア    BOOL 
    HttpOnlyのBOOL 
    生       文字列は
    未解析の[] の文字列 // 未解決」特性-元のテキストの値」 
}

Cookieの設定

net/httpこれは、次の提供するSetCookieHTTPヘッダー値クッキーのヘッダフィールドW Set-Cookieヘッダーに追加された機能を、。

FUNCますsetcookie（ResponseWriterワット、クッキー*クッキー）

クッキーの取得

Requestクッキーオブジェクトは、二つの取得の方法およびクッキーを添加する方法があります。

クッキーの二つの方法：

// リクエストを解析し、すべてのクッキーのクッキーヘッダのセットを返し 
FUNC（R *リクエスト）クッキー（）[] * クッキー

//をクッキーを返すゼロ、ErrNoCookieが見つからない場合、リクエストで指定されたクッキーの名前を返します。
FUNC（R＆LT *リクエスト）クッキー（名前文字列）（*クッキー、エラー）

クッキーのメソッドを追加します：

// addCookieは、リクエストにクッキーを追加します。
FUNC（R *リクエスト）AddCookie（ C *とクッキー）

ジンフレームの操作クッキー

インポート（
     " FMT " 

    " github.com/gin-gonic/gin " 
）

FUNCメイン（）{ 
    ルータ： = gin.Default（）
    router.GET（" /クッキー"、FUNC（C *とのgin.Context）{ 
        クッキー、 ERR： = c.Cookie（" gin_cookie "）// 获取クッキー
        ならば！誤る= nilの{ 
            クッキー = " NOTSET " 
            // 设置クッキー 
            c.SetCookie（" gin_cookie "、"テスト" 3600、" / " " ローカルホスト" 偽、真）
        } 
        fmt.Printf（" クッキー値：％Sの\ n " 、クッキー）
    }）

    router.Run（）
}

セッション

セッションの起源

クッキーがある程度解決しますが、要件を「ホールド」が、4096バイトの最大サポート自体クッキー、クッキーやクライアント自体に保存されているため、傍受または盗難することができるため、したがって、何か新しいものが必要とされて、それをより多くのバイトをサポートする、と彼は、サーバー上に保存され、高いセキュリティがあります。これがありますSession。

質問は「誰が。」サーバは、訪問者を知らない、ステートレスなHTTPプロトコルの特性に基づいて、ありますそして、前述したクッキーは、ブリッジの役割を果たします。

ユーザログインが成功した後、我々は特別なセッションとサーバー上の各ユーザーの一意の識別子を作成し、彼らが対応しています。どこで：

セッションは、ユーザの状態を追跡するために、サーバ上に格納されたデータ構造であり、このデータはクラスタ、データベース、ファイルに格納されてもよいです。
一意の識別は、しばしばと呼ばれるSession IDクッキーのユーザーに書き込むこと。

ユーザーのフォローアップ訪問、再びこのように、要求は、自動的に（含むクッキーデータを運ぶSession IDそれを通してサーバーは、）Session IDまた、人々に知られている対応するセッションデータを、見つけることができるようになります「」

結論：クッキーまでステートレス不足HTTPのために、サーバは「」人々に知らせて、テキスト形式のクッキーは、ローカルに保存されているが、彼らのセキュリティが貧弱であり、私たちは別のクッキーを介してユーザを識別することができ、セッションのためのデータ・サーバを節約するために、各ユーザに対応し、セッションデータは、ユーザー固有のデータで保存することができます。

さらに、上記の事実は、クッキーとセッション共通のものは、ない言語やフレームに制限されています。

ゴークッキーとセッションの言語の基礎