go - gorilla/context 与 gorilla/sessions 有何不同？

Question

我得到 session ，来 self 曾经使用的 PHP

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

在服务器端设置一个或多个键及其值，并能够检索或覆盖它，直到 session 过期。

与 gorilla / session 相同

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"])
}

现在我不明白 gorilla /上下文的意义是什么。我知道上下文是什么，但是...我不知道它如何适应大局。它说它绑定(bind)到当前请求。 stackoverflow 上的另一个问题是在 Writing Per-Handler Middleware 的上下文中“仅使用 gorilla/context 就足够了”。

但如果是请求绑定(bind)... err.. 语法错误，不计算。如果鸭子漂浮在水面上，那么女巫是用木头制成的。而且因为鸭子也能浮在水面上，如果她的体重和鸭子一样，她一定是个女巫。或者类似的东西;)

当它被请求绑定(bind)时，它作为中间件“管理器”如何有用，我无法全局设置它。您能否举例说明如何将 gorilla/sessions 与 gorilla/context 一起使用？

Answer 1

作为提出其他问题的人:

• gorilla/context 允许您在请求中存储数据。如果您有一些中间件在决定继续之前对请求进行了一些预处理(即反 CSRF)，您可能希望在请求中存储一个 token ，以便您的处理程序可以将其传递给模板。 gorilla/context documentation explains it well :

... a router can set variables extracted from the URL and later application handlers can access those values, or it can be used to store sessions values to be saved at the end of a request. There are several others common uses.

• 您可能还想在 session 中存储数据:来自表单提交的错误消息、用户 ID 或该访问者的 CSRF token 的“规范”版本可能会存储在这里。如果您尝试在请求上下文中存储错误消息，然后重定向用户，您将丢失它(这是一个新请求)。

那么为什么要在 session 上使用上下文呢？它更轻巧，允许您将应用程序的各个部分(通常是 HTTP 中间件!)彼此分离。

例子:

1. 请求进来
2. CSRF 中间件会检查 session 中是否存在现有的 CSRF token 。不存在，因此设置为 1。
3. 它还将这个新 token (通过请求上下文!)传递给呈现您的表单的处理程序，因此它可以在模板中呈现它(否则您将不得不再次从 session 中提取 token ，这是浪费精力)
4. 请求已完成。
5. 关于表单提交的新请求
6. token 仍保留在 session 中，因此我们可以将其与表单中提交的 token 进行比较。
7. 如果 checkout ，我们会继续处理表单
8. 如果没有，我们可以在 session 中保存一个错误(一条闪存消息；即在阅读后删除的消息)并重定向。
9. 此重定向是一个新请求，因此我们无法通过此处的请求上下文传递错误消息。