「让用户把附件中的 index.html 放到服务器上」，路子真野。。

可以看一下帮助节点。
@Livid /go/newbie

@yujinchn776
@MrGba2z
我是自己搭自己用的，每月 5 ，6 美元哪。

@joefuzhou198x
@hsir
登录了，之前管用，现在也不行。

@churchmice
chatgpt 可以破解验证码啊，无论多么复杂的。(待验证)

「目标是。。通用型数据记录与分析工具。。通用型就是不针对具体场景。。这是我想到的目标用户」

我看了下楼主的 App ，楼主你没有把 App 的特色表达出来啊：展示的图片里面，没有展示最关键的模版功能。也没有一个官方网站来说明「通用型」这个特色是怎么用的，尤其是是怎么用模版来实现通用的。

「隔靴搔痒」，大量“炫耀”的篇幅只是勾起了痒，喧宾夺主了。偶尔点缀当然可以挑逗味蕾，可你只贴出账单，却不贴出如何拿到这些账单的经验，缺少营养。

前面几楼的回复不就是鲜明的例证吗。

@maxxfire 说得对。
这 8 篇文章看下来，给我的印象是：
蜻蜓点水
浅尝辄止
隔靴搔痒
俘于空中
品咂无味
惹人上瘾

8 篇文章的重点在于贴账单，炫美车美景美食，勾起欲望。缺少实例。唯一的产品例子，就是那个安卓桌面程序。

第一篇介绍 Broken Screen 这款应用的实例，暧昧不清，总让人觉得这是你开发的。朦胧美好的味道，这也就是卖课的高端境界吧，哈哈。

@pkoukk #72 对，闲鱼应该没啥问题。我之前一直以为确认收款的操作是闲鱼发给支付宝的。流水号一致的要求也挺合理。

@Rache1
「如果这个交易号暴露给了卖家，那么卖家也可以作为发起人了」，我这里说的卖家作为发起人就是指主题里的那种诈骗手段：卖家诱骗买家确认收货。这也可以看作是卖家作为发起方吧。前提就是卖家有这个交易号。

我理解了你的意思是不是说，支付宝担保交易这种，从头到尾，也只有一个交易号，并且这个号同时被买家、闲鱼、卖家共享？担保交易相对于直接交易，多了一个中间状态，对于买家来说，是已付款待确认，而对于卖家来说则是已付款未收款。是这样吗？

如果是这样，交易号是统一且共享的，那么是不适合作为 API 的参数来用的，比如对于买家来说确认收货的 API 。支付宝完全可以针对每一个交易号，再产生一个对应的确认收货号，并且仅下发给闲鱼。然后闲鱼才可以使用这个收货号，在 App 中让买家发起确认收货的操作。由于这个确认收货号只会在交易过程中才使用，交易完毕可以废弃，所以不影响最终的交易结果和数据归档。就相当于是一个对应于某种操作权限的 token 。

@codehz 但是确认收货的发起人肯定是闲鱼。从业务上来说，也只有闲鱼 app 上才有确认收货的入口才合理。闲鱼暴露给用户的，只有一个“确认收货”的按钮，用户经由这个按钮“代理”才可以触发收货，进而启动支付宝的支付密码确认。
主题提到的骗钱手段，能成功的原因，一是卖家伪装成闲鱼，向支付宝发起了确认收货的操作，二是确认收货所必须的信息(支付宝交易号)被暴露给了卖家。

@Rache1 #56
「 AlipayJSBridge.call("tradePay", { tradeNO: "2023042622001174211404250439" }, function(result) {});」
这个里面的 2023042622001174211404250439 ，应该就是你说的支付宝交易号吧。如果这个号是闲鱼在创建订单的时候生成的，那么这个号是否有必要暴露给买家和卖家呢？「买家在闲鱼 App 里面点击确认收货按钮」，这个时候闲鱼才应该从后台拿到 2023042622001174211404250439 这个交易号，发起确认收货，由用户在支付宝上输入密码确认。支付宝是确认的一方，但是发起的却是闲鱼。如果这个交易号暴露给了卖家，那么卖家也可以作为发起人了。这也就是不必要的信息暴露导致的风险。
所以一个关键的问题就是，这个交易号是不是必须暴露给卖家（比如卖家伪装取消订单拿到了这个交易号）。如果存在这种暴露的可能性，是不是可以进一步改进这种交易号的设计（应该由支付宝来做）。

@xmumiffy 或者这么理解，订单号对于谁可见，本质上是业务上的必要性的问题。如果一个订单号可以只对闲鱼可见，那么就无需暴露给买家和卖家。对于任何一方，都只暴露给其所需的最小信息量。这样攻击面也会最小化。支付宝的买家和卖家直接交易中，双方都可以见到支付宝交易的订单 ID ，便于双方核对。

那么闲鱼作为中间方的担保交易也是这样吗？买家的钱首先是打给闲鱼的，而不是打给卖家，所以订单 ID 应该也分成买家和闲鱼、闲鱼和卖家这 2 份，至于它们后台共享同一个业务 ID ，那这个 ID 应该是只对闲鱼可见的。我不懂支付业务，但直觉上感觉是应该这样设计的。

@xmumiffy 订单号足够长的话，就是能起到密码的作用，也可以起到与密钥同等的效力。这点不用怀疑吧。如果可以做到的话，那么逻辑上是更完整的。再加上你说的鉴权行为，相当于是两道加密的效果。这两道加密没有什么主次之分。

@coolcoffee
@cyansto
我搜了下“支付宝确认收货”，还真有这个接口。。没有交易金额，只输入确认密码。

那现在问题比较清楚了，支付宝在收到确认收货的调用时，没有做域名校验，这应该是主责。但是，闲鱼的设计是不是有漏洞呢？按常理，「确认收货」这个动作，只有在买家的闲鱼 App 里面才可以操作，对吧，但由于卖家获取到了订单的 ID ，直接调用了支付宝的接口，实现了确认收货。

这里面闲鱼的处理逻辑是有漏洞的，因为订单的 ID 对于买家和卖家，应该都不可见才对，尤其是对于卖家。只有在买家点击「确认收货」时，才由闲鱼 App 从后台获取到这个订单 ID ，然后发起支付宝确认操作。这样，就类似于 @coolair 所说的「买家订单号和卖家订单号分开来生成」了，卖家是无法见到这个订单 ID 的，卖家应该也用不到这个订单 ID （即使是卖家取消订单？）。

我不知道支付宝的担保交易的逻辑，生成订单 ID 的逻辑是什么样的，生成的订单 ID 是不是只是对于闲鱼可见，还是对买家和卖家都可见。如 @coolair 那样的方案，在密码学上更严谨。像 @fydpfg 所说的，「正确使用密码学来保证协议的安全性」

@coolcoffee #18 >“。。匿名调用订单核心操作，这个锅得让支付宝来背。。”
@cyansto

你们能相信支付宝有「确认订单完成」的接口或功能吗？支付页面肯定要显示支付金额的，我没有见过只输入支付密码的而没有交易金额显示的，想想也不符合实际场景啊。所以，我觉得应该不是支付宝的问题。而是闲鱼的 bug 。

“确认收货”这个肯定不是支付宝能够做出的动作。这一点成立的话，那么无论支付宝作出什么动作，闲鱼都不应该确认交易完成，并给卖家放款，因为确认交易完成只能买家在闲鱼 App 里面才能触发。

@functioncloud
如果是对闲鱼订单的支付，那么支付宝的支付页，显示的就是实际金额吧。