9

以前使用していた PHP からセッションを取得します

<?php
session_start();
$_SESSION["key"] = "val";
echo $_SESSION["key"];
?>

1 つ以上のキーとその値をサーバー側で設定し、セッションが期限切れになるまで取得または上書きできるようにします。

ゴリラ/セッションと同じ

var(
    sessionStore  *sessions.CookieStore
    sessionSecret []byte = make([]byte, 64)
    session       *sessions.Session
)

func init(){
    sessionSecret = []byte("12345678901234567890123456789012")
    sessionStore = sessions.NewCookieStore(sessionSecret)
    session = sessions.NewSession(sessionStore, "session_name")
}

func SetSessionHandler(w http.ResponseWriter, r *http.Request) {
    session, _ = sessionStore.Get(r, "session_name")
    session.Values["key"] = "val"
    session.Save(r, w)
}

func GetSessionHandler(w http.ResponseWriter, r *http.Request) {
    session, _ = sessionStore.Get(r, "session_name")
    fmt.FPrintln(session.Values["key"])
}

今、ゴリラ/コンテキストのポイントがわかりません。コンテキストが何であるかは知っていますが... 全体像にどのように適合するかはわかりません。現在のリクエストにバインドされていることを示しています。ここでのスタックオーバーフローに関する別の質問では、ハンドラーごとのミドルウェアの記述のコンテキストで「ゴリラ/コンテキストを使用するだけで十分だ」と述べています。

しかし、それがリクエストバウンドの場合...エラー..構文エラーであり、計算されません。アヒルが水に浮かぶ場合、魔女は木でできています。また、アヒルも水に浮くので、アヒルと同じ体重なら魔女に違いありません。またはそのようなもの;）

そして、これがリクエストにバインドされている場合、ミドルウェアの「マネージャー」としてどのように役立つのでしょうか。グローバルに設定することはできません。ゴリラ/セッションをゴリラ/コンテキストで使用する方法の例を示していただけますか?

4

2 に答える 2

9

その他の質問をした人として：

  • gorilla/context を使用すると、リクエストにデータを保存できます。続行を決定する前にリクエストの前処理を行うミドルウェア (つまり、反 CSRF) がある場合は、ハンドラーがテンプレートに渡すことができるように、リクエストにトークンを保存することをお勧めします。ゴリラ/コンテキストのドキュメントはそれをよく説明しています:

... ルーターは URL から抽出された変数を設定でき、後でアプリケーション ハンドラーはそれらの値にアクセスできます。または、リクエストの最後に保存されるセッション値を保存するために使用できます。他にもいくつかの一般的な用途があります。

  • セッションにデータを保存することもできます。フォーム送信からのエラー メッセージ、ユーザー ID、またはその訪問者の CSRF トークンの「正規」バージョンは、おそらくここに保存されます。エラー メッセージをリクエスト コンテキストに保存してからユーザーをリダイレクトしようとすると、それが失われます (これは新しいリクエストです) 。

では、なぜセッションよりもコンテキストを使用するのでしょうか? より軽量で、アプリケーションの一部 (多くの場合、HTTP ミドルウェア!) を互いに切り離すことができます。

例：

  1. リクエストが来る
  2. CSRF ミドルウェアは、既存の CSRF トークンのセッションをチェックします。存在しないので設定します。
  3. また、この新しいトークンを (リクエスト コンテキストを介して!) フォームをレンダリングするハンドラーに渡すため、テンプレートでレンダリングできます (そうしないと、セッションからトークンを再度取得する必要があり、無駄な労力になります)。
  4. リクエストが行われます。
  5. フォーム送信時の新規リクエスト
  6. トークンは引き続きセッションに保持されるため、フォームから送信されたトークンと比較できます。
  7. チェックアウトすると、フォームの処理に進みます
  8. そうでない場合は、エラーをセッションに保存し (フラッシュ メッセージ、つまり、読み取り後に消去されるメッセージ)、リダイレクトすることができます。
  9. このリダイレクトは新しいリクエストであるため、ここでリクエスト コンテキストを介してエラー メッセージを渡すことはできません。
于 2013-12-06T03:30:04.520 に答える