TimothyQiu's Blog

keep it simple stupid

使用支付宝「移动支付」同步通知时遇到的问题与吐槽

移动支付」是支付宝推出的针对手机移动支付的服务。虽然支付宝现在建议新商户转用「App 支付」接口了,但是一些较早接入的 App 仍旧在使用这个服务,比如鄙厂的智能证件照 ;-)

各大支付服务的套路其实都是一样的,无论网页还是 App:

  1. 服务器为支付所需数据签名
  2. 客户端使用签名后的数据调起支付服务
  3. 用户支付成功后,客户端获得支付结果同步通知,服务器获得异步通知回调

显然支付状态应以服务器获得的异步通知为准,不过某些情况下,客户端可能会有在先检查一下本地的支付结果有效性的需求。

前些天在 Sentry 里收到了错误报告,原因是校验客户端获得的同步通知结果时,发生了「被校内容格式异常」的错误。初以为是有人故意修改了客户端在捣乱,检查请求内容才发现,原来是支付宝(不知为何)本次发来的同步通知内容使用了不同以往的格式:

partner="2088101568358171"&seller_id="xxx@alipay.com"&out_trade_no="0819145412-6177"&subject="测试"&body="测试测试"&total_fee="0.01"&notify_url="http://notify.msp.hk/notify.htm"&service="mobile.securitypay.pay"&payment_type="1"&_input_charset="utf-8"&it_b_pay="30m"&success="true"&sign_type="RSA"&sign="hkFZr+zE9499nuqDNLZEF7W75RFFPsly876QuRSeN8WMaUgcdR00IKy5ZyBJ4eldhoJ/2zghqrD4E2G2mNjs3aE+HCLiBXrPDNdLKCZgSOIqmv46TfPTEqopYfhs+o5fZzXxt34fwdrzN4mX6S13cr3UwmEV4L3Ffir/02RBVtU=";extendInfo="doNotExit":true,"isDisplayResult":true

末尾前无古人后无来者地加了个分号,然后以奇怪的格式引入了 extendInfoisDisplayResult 两个字段。这是文档中从来没有提过会发生的事情。

原本通过文档中字段说明及例子,我们可能还觉得返回的支付结果就是用的 HTTP Query String 格式,而且支付结果去除涉及签名的 signsign_type 相关键值对后可以直接用来验证签名。收到这回这么一条回调,就都不成立了。

所幸原先为了偷懒没有以 HTTP Query String 的格式解析支付结果,而是直接用正则表达式 ^(.+)&sign_type="RSA"&sign="(.+)"$ 从中提取待签名字符串及签名本身。(偷懒之处在于:因为如果解析以后,按照支付宝的签名规则,我还得再把它们重新排序;而解析前的键值对本身已经是排过序的了。)

但不幸的是,这个正则表达式认为 sign="xxxx" 后不应该有任何多余数据。于是便有了「被校内容格式异常」。

反思及吐槽

前两天刚在知乎大言不惭地在回答里说很多程序员不肯看文档、凭直觉掩耳盗铃地写代码,结果这就立马变成自我吐槽了 ;-(

其实仔细看支付宝的文档的话,关于同步通知中的支付结果和签名,是这样说的:

result:本次操作返回的结果数据。其中:&success="true"&sign_type="RSA"&sign="xxx"之前的部分为商户的原始数据。success用来标识本次支付结果。sign="xxx"为支付宝对本次支付结果的签名(加签内容为:案例中原始数据&支付结果,……)

首先,你看文档里确实并没有保证支付结果数据始终以 sign="xxx" 结尾。我在正则表达式里作出那样的假设,是基于例子退出的假设,但这其实是个高中数学「充要条件」的问题。

其次,我那偷懒利用结果数据中「已排序」特性的操作,虽然目前并没有什么问题,但其实也是有风险的。因为文档里并没有保证它的有序性。

所以嘛,我错了,我应该好好看文档的……

以上,真是有意义的一天呐~

自旋锁、互斥器、条件变量及读写锁

这是上个礼拜难得没有犯懒,为知乎的问题《如何理解互斥锁,条件锁,读写锁以及自旋锁?》写的一个比较长的回答。

阅读剩余部分...

std::error_code 和它的朋友们

前几天看 API 文档时候遇到了 std::error_code 这个东西,当时以为是 errno 的 Alias,后续查阅文档才发现并没有那么简单。

阅读剩余部分...

从 feedly 投向 inoreader

当年 Google Reader 拜拜后,我也陆续尝试了不少国内国外的替代品。当时选择了相对不错的 feedly,但因为不像 GR 一样存在感强烈,常常忘掉它的存在。最近整理阅读渠道,又把 feedly 拾起来,就感觉到了 feedly 的不足。

阅读剩余部分...

自定义 Xcode 文件模板

几年前初次接触 Xcode,就觉得它的默认的代码模板很不好:

当时毕竟还是 Too Young,刚接触 OS X,照着奇怪的教程跑去 /Applications/Xcode.app 里乱改一气,虽然达到了目的,但总觉得有些怪味道,就不了了之了。

最近终于有机会重新折腾一下 Xcode,就又查了一下相关的内容。不得不说,Xcode 这方面文档真是太不友好了 =,=

自定义文件模板

/Applications/Xcode.app 里是应用自己的原生内容,不应该擅自修改。要修改文件模板,应该把对应的位于 /Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates.xctemplate 模板文件夹复制到 ~/Library/Developer/Xcode/Templates 改个名字后,再加以修改。

# 创建文件夹结构(默认没有 Templates 及往后的文件夹)
mkdir -p ~/Library/Developer/Xcode/Templates/File\ Templates/Source

# 复制需要修改的 .xctemplate 文件夹
# 这里是在 Source 分类下,将 Swift File 模板复制为 Empty Swift File 模板
cp -R /Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File\ Templates/Source/Swift\ File.xctemplate/ ~/Library/Developer/Xcode/Templates/Source/Empty\ Swift\ File.xctemplate/

这样,修改 Empty Swift File.xctemplate/___FILEBASENAME___.swift 就可以把讨厌的注释去掉了。

这里没法修改原有模板,也没法覆盖。即便使用与 Xcode 自带模板相同的名称,也只会在新建文件的模板选择对话框里出现两个同名的模板,非常蛋疼。

细枝末节

由于相关文档不足,我又有点强迫症,于是尝试了一些东西,比如上面说的「使用与 Xcode 默认模板相同的名字没法覆盖默认模板」。

上面路径中的 ~/Library/Developer/Xcode/Templates 为用户自定义模板的根目录,这个目录下的 .xctemplate 文件夹会被 Xcode 加载。Xcode 模板中的「分类」与此处 .xctemplate 的父目录有关。

虽然最后两种在效果上没什么区别,但还是推荐使用最后一种,与 Xcode.app 中的目录结构对应起来,会比较方便管理。

另外,使用向导填写模板参数的高级用法需要查找官方 Reference,不过粗略找了一下也没有找到官方说明,很是沮丧 :( 不过反正目前用不到 :)