Go 的许多书籍和博客中大量使用了两种身份验证方法:

使用 http.Request :

func getCurrentUser(r *http.Request) (*User, error) {
    // get JWT token or cookie and find corresponding sessions 
    // and account, then return the user and nil error;
    // if user is not found, return a nil user and a non-nil error
}

然后处理函数调用 getCurrentUser 来获取每个用户 要求。可以使用环绕的函数装饰器 其他处理程序并在其他处理程序函数之前检查身份验证 被处决。

func secretInfoHandler (w http.ResponseWriter, r * http.Request) {
     user, err := getCurrentUser(r)
     if err != nil {
          // write http.Unauthorized, and return
     }
     // otherwise, process request return data
}
func MustAuthenticate (h http.HandlerFunc) http.HandlerFunc {
    return func (w http.ResponseWriter, r *http.Request) {
          // chekc authentication, if pass:
          h.ServeHTTP(w, r)
          // if fail:
          w.WriteHeader(http.StatusUnauthorized)
          return
    }
}

使用 context.Context :

// use the same getCurrentUser() as the one above
func MustAuthenticate (h http.HandlerFunc) http.HandlerFunc {
    return func (w http.ResponseWriter, r *http.Request) {
        user, err := getCurrentUser(r)
        if err != nil {
            // write error code then return
        }
        ctx := context.WithValue(r.Context(), someKey, someValue)
        h(w, r.WithContext(ctx)) 
    }
}

然后对于每个处理程序(如 secretInfoHandler )，而不是调用 getCurrentUser(r *http.Request) , 我只需要检查 Context http.Request 附带的包含某些身份验证信息。

它们看起来是等价的。那么，每种方法的技术优势/劣势是什么？如果它们确实等效，那么哪个更适合用于实际生产代码？

最佳答案

我觉得你的例子有点困惑。它们似乎包含在处理程序中授权和在中间件包装处理程序中授权的组合。

处理程序中的授权(使用 getCurrentUser)

这是第一个示例，从请求处理程序调用一些 getCurrentUser(request) 函数。

func secretInfoHandler (w http.ResponseWriter, r * http.Request) {
     user, err := getCurrentUser(r)
     if err != nil {
          // write http.Unauthorized, and return
     }
     // otherwise, process request return data
}

^^ 这是取自您的示例，但您还包括了我认为与此处无关的 MustAuthenticate 中间件。

作为中间件的授权(使用上下文)

这是您的第二个示例，使用 context.Context 的键值桶作为将值向下发送到处理程序的方式。

func MustAuthenticate (h http.HandlerFunc) http.HandlerFunc {
    return func (w http.ResponseWriter, r *http.Request) {
        user, err := getCurrentUser(r)
        if err != nil {
            // write error code then return
        }
        ctx := context.WithValue(r.Context(), someKey, someValue)
        h.ServeHTTP(w, r.WithContext(ctx)) 
    }
}

比较

请务必从一开始就注意；虽然我将这两个分为处理程序中的 auth 和中间件中的 auth，每个都有自己的 using。没有理由不能交换授权发生的方式。例如使用 getCurrentUser(request) 在中间件中授权，您是否应该在下面讨论。

分解一下，你真正需要问的问题是:

“您需要在哪里访问您的用户结构？”

这将帮助您决定使用哪个。

一般来说，将请求范围的变量放在 context.Context 中是完全有效的。跟踪信息等变量会定期进入上下文。 context 的主要问题是它没有在编译时检查，而且类型不安全。您在后面的代码中假设您的用户对象已在上下文中设置，这使得您的代码以一种不明显的方式耦合。

context.Context 方法的好处是，如果您的用户对象需要下降到多个函数调用级别，则无需将其连接到整个代码库。您可以稍后将其从上下文中提取出来。它是一个值桶，允许以后在代码中具有更大的灵 active 。

在handlers方法中授权；您可能在许多处理程序中拥有相同的授权和错误处理代码。如果您尝试将其提取到中间件；您很快就会发现，没有很好的方法来维护 http.Handler 接口(interface)并传递从中间件中提取的用户对象。 (这就是为什么在上面的示例中，用户对象被放在请求对象中的原因)。

在 Controller 中使用 getCurrentUser(request) 进行授权的好处在于，用户结构的创建位置一目了然，通过该处理程序可以清楚地知道发生了什么授权，而用户不可能对象不存在(假设没有返回错误)。

长话短说

取决于你在哪里需要你的用户对象；以及有多少处理程序。

1. 很少的处理程序，不需要用户外部处理程序:getCurrentUser(req)内部处理程序
2. 许多处理程序，不需要用户外部授权:中间件中的 getCurrentUser(req)，并且不要将其放在上下文中(因为您不需要稍后)
3. 许多处理程序，稍后在代码中需要用户:中间件中的授权，将用户放在上下文中，稍后再取出。

关于使用请求与上下文的身份验证，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51224251/