解决 php post 而 gin 收不到问题

缘由

php 这边用 post+json 形式向 golang 的 gin 框架发送数据,之前网页版都是使用正常,最近有个需求是一个功能接入移动端内部办公系统,通过接入 sdk 调用实现网页上的功能。

现象

php 作为业务代理层,会接收客户端传过来的数据,然后通过封装的 curl 库发送给 golang 微服务。但是这次在接收到 sdk 的发过来的数据,组装加工并转发到 gin 时,却一直报错。

 "Key: 'SubmitReq.TaskID' Error:Field validation for 'TaskID' failed on the 'required' tag
 
Key: 'SubmitReq.ResultStatus' Error:Field validation for 'ResultStatus' failed on the 'required' tag"

熟悉 gin 的童鞋就应该知道,这是 shouldBind 报出的,也就是 SubmitReq 这个结构里有两个必传字段,但是在接收时,却没有收到,因此报错。

type SubmitReq struct {
	TaskID       string                 `form:"taskId" json:"taskId" binding:"required"`
	ResultStatus int64                  `form:"resultStatus" json:"resultStatus" binding:"required"`
}

var submitReq structure.submitReq
if err := c.ShouldBind(&submitReq); err != nil {
	rsp.Errno = config.ErrnoParams
	rsp.Errmsg = err.Error()
	c.JSON(http.StatusOK, rsp)
	return
}

解决

首先是完善 gin 入口那的接收 http 请求日志

log.Infof("_com_request_in||%v||from=%v||uri=%v||url=%v||method=%v||contentType=%v||header=%+v||args=%v", traceInfo, c.ClientIP(), c.Request.URL.Path, c.Request.URL, c.Request.Method, c.Request.Header.Get("Content-Type"), c.Request.Header, string(data))

接下来就是模拟发送了,并通过三次发送,定位到了问题。

最开始,模拟实际情况,先到 php 服务上找到当时 sdk 发过来的日志,然后拿到发送的数据,模拟发送,在 gin 服务上发现日志中的 method 为 post,而 contentType 和 args 都为空,这就很有问题。

翻了翻源码,发现 contentType 为空时,会按照下载逻辑处理。实际上,就是不处理参数,接收值为空,也就报上述的错误了。

func parsePostForm(r *Request) (vs url.Values, err error) {
	if r.Body == nil {
		err = errors.New("missing form body")
		return
	}
	ct := r.Header.Get("Content-Type")
	// RFC 7231, section 3.1.1.5 - empty type
	//   MAY be treated as application/octet-stream
	if ct == "" {
		ct = "application/octet-stream"
	}
	ct, _, err = mime.ParseMediaType(ct)
	switch {
	case ct == "application/x-www-form-urlencoded":
		var reader io.Reader = r.Body
		maxFormSize := int64(1<<63 - 1)
		if _, ok := r.Body.(*maxBytesReader); !ok {
			maxFormSize = int64(10 << 20) // 10 MB is a lot of text.
			reader = io.LimitReader(r.Body, maxFormSize+1)
		}
		b, e := io.ReadAll(reader)
		if e != nil {
			if err == nil {
				err = e
			}
			break
		}
		if int64(len(b)) > maxFormSize {
			err = errors.New("http: POST too large")
			return
		}
		vs, e = url.ParseQuery(string(b))
		if err == nil {
			err = e
		}
	case ct == "multipart/form-data":
		// handled by ParseMultipartForm (which is calling us, or should be)
		// TODO(bradfitz): there are too many possible
		// orders to call too many functions here.
		// Clean this up and write more tests.
		// request_test.go contains the start of this,
		// in TestParseMultipartFormOrder and others.
	}
	return
}

第二次,找到 php 中 curl 填充 header 的 Content-Type 处的代码,发现有逻辑漏洞

if (!empty($userInfo)) {
    $headerContentType = !empty($contentType) ? $contentType : $_SERVER['HTTP_CONTENT_TYPE'];
    $ctx->extHeaders = ["userinfo: " . json_encode($userInfo, JSON_UNESCAPED_UNICODE), "Content-Type: " . $headerContentType];
}

如果上游接口中,传了 $userInfo 但是 $contentType 为空,这时 $_SERVER['HTTP_CONTENT_TYPE'] 若为空,就是最开始时的错误。后来通过打印 php 的日志也发现了这点,Content-Type 确实为空。

于是,补充了下相关逻辑,加上了 application/json; charset=utf-8 ,并发送了模拟请求。不过依然是第一次报的错误。

第三次,仔细看了下 gin 打印的日志,终于发现了端倪,在 method 是 POST,Content-Type 是 application/json; charset=utf-8 情况下,参数 args 为

taskId=1&resultStatus=1

本来应该要传 json 格式的,可传的是 form 形式的(也可以说是 queryString 的)。虽然, gin 支持 json、form 和 queryString 三种格式数据解析,但是在 method 和 header 头类型都确定的情况下,没传 json ,而是其他格式的,难怪会解析报错。

func (jsonBinding) Bind(req *http.Request, obj interface{}) error {
	if req == nil || req.Body == nil {
		return fmt.Errorf("invalid request")
	}
	return decodeJSON(req.Body, obj)
}

问题,还是出现在 php 封装的 curl 代码那

curl_setopt($ci, CURLOPT_POSTFIELDS, is_string($params) ? $params : http_build_query($params));

原来最后发送数据这里,是不管前面设置啥 Content-Type 的,由于前面传的是数组,这里肯定会以 form 形式传过去的。

解决,也很简单,就是在上游收敛了传的 Content-Type 和 params 数据,这样就不会出现挂羊头卖狗肉的情形了。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值