Go CrossOriginProtection 被拒绝时怎么返回自定义响应

在 Go 的 net/http 中，想把跨源请求被拒绝时的默认 403 改成统一 JSON，关键是先对同一个 CrossOriginProtection 调用 SetDenyHandler，再用它的 Handler 包装业务处理器。这样，检查失败时标准库会把请求交给你设置的拒绝处理器。

官方地址：https://pkg.go.dev/net/http#CrossOriginProtection.SetDenyHandler

如果使用 protection.Handler(mux)，拒绝响应由 SetDenyHandler 定制；如果直接调用 protection.Check(req)，它只返回 error，不会自动调用拒绝处理器，响应内容必须由调用方自己写。

Handler 为什么能接管拒绝响应

CrossOriginProtection.Handler 返回一个新的 HTTP 处理器。请求进入后，它先调用内部检查；没有错误时继续执行被包装的业务处理器，有错误时优先调用通过 SetDenyHandler 设置的处理器。没有设置时，标准库才使用默认的 403 响应。

因此，自定义响应的入口不是业务处理器里的某个分支，而是保护对象本身的拒绝处理器。把配置放在包装动作之前，能让所有经过同一层的拒绝请求使用相同格式。

用 SetDenyHandler 返回统一 JSON

下面的写法把拒绝响应集中成一个 http.Handler。注意要先写响应头，再写状态码，最后输出正文；业务处理器只负责真正被允许的请求。

package main

import (
	"log"
	"net/http"
)

func main() {
	protection := http.NewCrossOriginProtection()

	// 统一处理跨源检查失败的响应，不参与业务登录或权限判断。
	protection.SetDenyHandler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Content-Type", "application/json; charset=utf-8") // 先声明响应格式
		w.WriteHeader(http.StatusForbidden)                                  // 明确返回 403
		_, _ = w.Write([]byte(`{"error":"cross-origin request denied"}`))    // 输出稳定的错误结构
	}))

	mux := http.NewServeMux()
	mux.HandleFunc("/profile", func(w http.ResponseWriter, r *http.Request) {
		// 能执行到这里，说明请求已经通过 CrossOriginProtection 的检查。
		w.WriteHeader(http.StatusNoContent)
	})

	server := &http.Server{
		Addr:    ":8080",
		Handler: protection.Handler(mux), // 让保护层位于业务路由之前
	}
	log.Fatal(server.ListenAndServe()) // 生产环境应配合优雅退出和超时设置
}

这段代码只定制“被保护层拒绝后如何回复”，不代表请求已经完成业务鉴权。登录状态、资源所有权和角色权限仍应在业务处理器或独立授权层中判断，不能因为跨源检查通过就直接放行所有业务操作。

SetDenyHandler 处理的是哪一类请求

拒绝处理器只会接收 Handler 这条包装链上、且跨源检查失败的请求。检查通过的请求不会经过它，而是继续进入 mux。所以拒绝处理器适合做格式统一、错误码统一和必要的请求日志，不适合承载正常业务逻辑。

CrossOriginProtection 对安全方法有自己的处理规则，并且还会依据请求头、可信来源和绕过模式判断是否拒绝。本文的边界只在响应定制：如果你需要调整哪些来源可信，应单独配置保护对象，不能在拒绝处理器里把所有 403 都改成成功响应。

直接调用 Check 时不会触发拒绝处理器

有些中间件链不适合直接套一层 Handler，而是希望先检查请求，再决定是否执行后续逻辑。这时可以直接调用 Check，但要记住：它只返回检查结果。即使已经设置过 SetDenyHandler，下面的错误分支也不会自动进入那个处理器。

func guarded(next http.Handler, protection *http.CrossOriginProtection) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if err := protection.Check(r); err != nil {
			// Check 只报告错误；这里必须由调用方决定状态码和响应格式。
			w.Header().Set("Content-Type", "application/json; charset=utf-8")
			w.WriteHeader(http.StatusForbidden)
			_, _ = w.Write([]byte(`{"error":"request rejected","detail":"cross-origin check failed"}`))
			return // 拒绝后不能继续调用 next，避免业务处理器误接收请求
		}

		// 检查通过才进入下一层，具体业务权限仍由 next 自己负责。
		next.ServeHTTP(w, r)
	})
}

这里的响应看起来和 SetDenyHandler 的输出相似，但它们是两条独立路径。前者是 Check 调用方自己的错误分支，后者是 Handler 内部在检查失败后代为调用的处理器。若希望全站格式完全一致，可以把生成错误响应的逻辑抽成普通函数，再分别从两个入口调用。

Handler 和 Check 怎么选

最常见的误区是设置了 SetDenyHandler，却在另一段代码里直接调用 Check，然后期待自定义 JSON 自动出现。排查时先看调用点：调用的是 Handler，还是只调用了 Check。

最后确认三个细节

1. 配置对象要一致：SetDenyHandler 必须设置在实际拿来调用 Handler 或 Check 的那个保护对象上。
2. 拒绝后要返回：自定义拒绝处理器和手动 Check 分支都应在写完响应后结束当前处理链。
3. 不要混淆边界：跨源保护负责请求来源检查，业务鉴权负责用户与资源权限，两者的通过条件不是一回事。

所以，标题中的“被拒绝时返回自定义响应”，最短答案就是：使用中间件形态时调用 SetDenyHandler，再把业务处理器交给 CrossOriginProtection.Handler；使用直接检查形态时，自己检查返回的 error 并写响应。

相关问题

不设置 SetDenyHandler 会怎样？

使用 Handler 包装时，检查失败会使用标准库提供的默认 403 拒绝响应。

SetDenyHandler 会被 Check 自动调用吗？

不会。Check 只返回错误；要统一响应格式，需要由调用方显式调用共享的错误响应函数。

自定义拒绝响应可以返回 200 吗？

技术上可以写任意状态码，但拒绝语义应保留为 403，否则监控、客户端和上游代理可能把被拦截请求误判为成功。