您现在的位置是:首页 > 文章详情

因 php 默认的 url encode 编码标准引发的一个问题

日期:2018-09-25点击:606

先看常用的校验请求合法性的一个方式

function createToken($params) { $secretKey = 'secretKey'; ksort($params); $query = http_build_query($params); $token = md5($query . $secretKey); return $token; } function createQuery($params) { $params['token'] = createToken($params); $query = http_build_query($params); return $query; } function checkQuery($params) { $token = $params['token']; unset($params['token']); return $token == createToken($params); } $params = [ 'k1' => 'v1', 'k2' => 'v2', 'time' => time() ]; $query = createQuery($params); echo $query, PHP_EOL; parse_str($query, $result); var_dump(checkQuery($result)); 

输出

k1=v1&k2=v%202&time=1537806711&token=e088ac85569f9eb5266026bb8da989b2 bool(true) 

client 每个请求都携带一个 token ,token 是由请求参数和一个 secret key 一起md5之后计算出来的, 然后 server 端使用同样的算法计算token(一般还会校验time,给 token 一个有效期,我这里简化了),然后对比 token ,保证请求的合法性。

乍一看,这个算法几乎天衣无缝,恩,我之前也是这么认为的,直到我用这个算法和一个 java 的服务交互时,才发现这个写法有些问题。

我在和 java 的同事连调时,有个请求总是报 token 校验错误,但是其他请求却没这个问题,我俩百思不得其解,互相 review 对方代码,也没有发现问题,然后和 java 的同事加了很多 log,终于发现了端倪。

我请求的参数里,有一个参数的值带有空格,然后我这边 url encode 之后

echo urlencode(" "); // + 

但是他那边 url encode 之后是

// 假装这里有 java url encode 的代码 %20 

这样,问题就很清晰了,不是算法问题,而是 url encode 的编码标准的问题。

php的 http_build_query (urlencode也一样)默认使用的 RFC 1738 (http://php.net/manual/zh/function.http-build-query.php)

默认使用 PHP_QUERY_RFC1738,如果 enc_type 是 PHP_QUERY_RFC1738,则编码将会以 RFC 1738 标准和 application/x-> www-form-urlencoded 媒体类型进行编码,空格会被编码成加号(+),如果 enc_type 是 PHP_QUERY_RFC3986,将根据 RFC 3986 编码,空格会被百分号编码(%20)。

而他那边用的是 RFC 3986 。

那么怎么规避这个问题呢?

常见的无非就是这两种方案,第一,两边使用同样的编码标准,第二,生成 token 的算法改一下,不要使用 url encode 之后的字符串加密(建议)。

更多架构、PHP、GO相关踩坑实践技巧请关注我的公众号:PHP架构师

原文链接:https://my.oschina.net/u/222608/blog/2208320
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章