Golang Go语言中tls.GetCertificate 方法中怎么设置上下文自定义变量或分享某些值
http.HandleFunc("/", func (...) {
// 2. 此处读取自定义的变量、值
} )
tlsCfg := tls.Config{
GetCertificate: func(info *tls.ClientHelloInfo) (*tls.Certificate, error) {
// 超级多域名
crt := getCertificateByApi(info.ServerName)
if crt == nil { return nil, errors.New(".....") }
// 这里怎么设置一个上下文的自定义变量呢
// 比如 getCertificateByApi 方法同时返回了其他关于这个域名在系统内的信息,比如系统到期时间等,然后 info.Context().Set("expire", "....")
// 但是 info.Context 只能读取又不能动态替换 Context..
return crt
},
}
srv := http.Server{TLSConfig : &tlsCfg}
srv.ListenAndServeTLS("","")
原因是,就趁着这一次接口请求,把该拿的数据都拿了。不想在 handle 里再请求一次接口。。
Golang Go语言中tls.GetCertificate 方法中怎么设置上下文自定义变量或分享某些值
更多关于Golang Go语言中tls.GetCertificate 方法中怎么设置上下文自定义变量或分享某些值的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
弄个全局变量上锁就可以了, 这有什么问题?
更多关于Golang Go语言中tls.GetCertificate 方法中怎么设置上下文自定义变量或分享某些值的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
是想让他跟着当前请求走,因为有些配置属性每次请求可能不一样
map 一个域名就可以了
另外一个系统在维护。随时会有变化。
。。看来只能重新实现一遍握手了…
server 端的证书跟着客户端请求走。。这种用法也太怪了吧?
TLS 握手交换验证证书在你 HandleFunc("/")之前就完成了,TLS 证书配置则必须在 http server 启动前就配置好。。你们需求是不是搞错了因果关系。。
并不奇怪啊,根据客户端请求的 SNI 下发不同的证书,或者根据客户端的版本兼容性下发 RSA/ECC 证书,这是个很常见的需求吧?
TLS 证书可以不在 http server 启动前配置,甚至可以等用户来请求了再去用 ACME 协议申请证书,然后缓存。
在Go语言的tls.GetCertificate
方法中,直接设置上下文(context)自定义变量或分享某些值并不是该方法的设计初衷。tls.GetCertificate
函数签名如下:
func (c *Config) GetCertificate(clientHello *tls.ClientHelloInfo) (*tls.Certificate, error)
它接收一个*tls.ClientHelloInfo
类型的参数,用于提供客户端Hello信息,并返回一个*tls.Certificate
和一个error
。
如果你需要在获取证书的过程中使用或分享某些值,可以考虑以下几种方法:
-
全局变量或单例模式:虽然不推荐,但在某些简单场景下,可以使用全局变量或单例模式来存储和访问所需的值。
-
闭包:将
tls.Config
的GetCertificate
方法设置为一个闭包,闭包中可以捕获并访问外部变量。 -
使用上下文(context)的间接方法:虽然
GetCertificate
方法本身不接受context.Context
,但你可以在创建tls.Config
之前,在更高层次(如HTTP服务器处理函数)中通过上下文传递所需的值,然后在GetCertificate
中通过其他方式(如全局状态管理或闭包捕获的变量)访问这些值。 -
自定义TLS握手处理:对于更复杂的场景,可能需要自定义TLS握手处理逻辑,但这通常涉及到底层TLS库的修改或扩展,不推荐除非非常必要。
选择哪种方法取决于你的具体需求和代码结构。