静态网站实现仅允许已完成Stripe支付的用户执行指定JS操作

核心结论 #

完全可以实现仅允许通过Stripe Checkout或支付链接完成支付的访客执行特定操作，但纯静态HTML+JavaScript无法做到安全的权限控制——前端代码可被任意篡改，用户能直接跳过支付校验逻辑，因此必须结合后端完成支付状态的验证。

实现逻辑与方案 #

1. 通用流程 #

不管用哪种后端架构，核心步骤都是一致的：

• 用户通过Stripe Checkout/支付链接完成支付；
• Stripe通过Webhook向你的后端发送支付成功通知，后端记录该用户的支付状态；
• 用户触发受限操作（上传图片、提交表单）时，前端先向后端请求验证当前用户的支付状态；
• 后端返回验证结果，前端据此放行操作或提示用户需先完成支付。

2. 是否必须部署后端？ #

是的，必须有后端：

• 前端无法安全验证支付状态：Stripe的支付凭证、会话信息在前端暴露后可被伪造，无法确保真实性；
• Stripe的Webhook只能发送给后端服务，无法直接通知前端；
• 需要存储用户与支付状态的关联信息（比如用邮箱、会话ID作为标识）。

3. AWS Lambda无服务器实现方案 #

用AWS Lambda替代传统服务器是非常合适的轻量化方案，具体步骤：

• 配置Stripe Webhook：在Stripe控制台设置Webhook端点为你的Lambda函数URL，监听checkout.session.completed事件；
• Lambda处理支付通知：收到Stripe的支付成功通知后，Lambda将用户标识（如会话ID、用户邮箱）和支付状态存入AWS DynamoDB；
• 前端发起验证请求：用户点击受限按钮时，前端调用另一个Lambda函数，传递当前用户的标识（比如从Stripe Checkout返回的会话ID，或用户输入的邮箱）；
• Lambda验证并返回结果：该Lambda从DynamoDB查询用户的支付状态，将结果返回给前端；
• 前端处理结果：验证通过则执行上传/提交操作，否则弹出需先支付的提示。

4. 关键安全细节 #

• Webhook签名验证：必须在Lambda中验证Stripe Webhook的签名，防止恶意伪造支付通知；
• 用户标识的选择：优先用Stripe返回的会话ID（唯一且不可篡改），或让用户提供支付时使用的邮箱进行匹配；
• 前端仅做辅助校验：可以在前端localStorage中临时存储支付状态标记，但最终权限判断必须以后端返回的结果为准。

内容的提问来源于stack exchange，提问作者user2348684