reddit · SaaS · 10-14 07:50 49 分 ← 返回列表

Corporate email scanners were using up my customers' sign-in links before they could click them

A customer at a large company wrote that our sign-in link just dropped them on the homepage. The database told the story: that morning they had asked for two links, both were marked as used within minutes, and neither turned into a login. What happened: their company's email security opens every link in incoming mail to check it. Our link signed you in on a plain GET, so the scanner's visit used it up. When the person clicked, the one-time code was gone, and our fallback sent them to the ho

五维评分

付费意愿

需求真实度

个人可落地

竞争空间

新鲜度

AI 分析

痛点：企业邮箱安全扫描器会自动预取邮件中的链接，把一次性魔法登录链接提前“用掉”，导致真实用户点击时链接失效、被静默跳回首页而无法登录。

目标用户：面向 B 端客户、用邮件魔法链接（magic link）做登录的 SaaS 独立开发者与小团队；以及自建 auth 的工程团队。

证据：that morning they had asked for two links, both were marked as used within minutes, and neither turned into a login. ... If you email sign-in links to business addresses, check what a plain GET does. Has anyone run into scanners that also submit forms?

变现：开源 npm 库做引流，托管版按 MAU 或按链接数收费（如 $19/月起，含滥用与扫描器检测、日志、多域名）；或作为 auth 服务的增值模块按座席/月订阅。

MVP：两周内做一个「scanner-safe magic link」SDK + 托管小服务：GET 只渲染带确认按钮的中转页（不消费 token）、POST 才校验并一次性消费、已用/过期链接给出明确提示与重发入口、响应头禁用缓存与 iframe、按钮防双击提交；附带一份扫描器 UA/IP 识别与埋点日志看板。

竞品：Auth0、Clerk、Stytch、WorkOS、Supabase Auth、Firebase Auth、Magic (magic.link)、Descope

摘要：一位做活动答题工具 EventQuiz 的开发者发现，某大企业客户早上申请的两条登录链接在几分钟内都被标记为已使用，却没有一次真正登录——原因是企业邮件安全扫描器预取并消费了 plain GET 的一次性链接。他的修复方式是把 GET 改为只展示确认页、由站内 POST 才消费 code，并对已用/过期链接给出提示，同时用几行 JS 防止按钮双击重复提交。这属于普遍且真实的开发者痛点，但修复成本极低、Auth0/Clerk/Stytch 等成熟 auth 服务已覆盖，独立开发者只能靠更轻量的 SDK + 托管服务切细分市场，付费意愿在帖中未被直接证明。