网站攻防与用户系统

发表于 分类于 评论数：
  • 项目目的: 1, 打造”多用户”站点 2, 防被人恶意攻击

自建token认证

  • jwt
  • CSRF
  • cors
  • CA机构, 自签名证书, let’s encrypt
  • SameSite=Lax
  • access token: 1h/短期/api操作, refresh token: 7天/签发access token
  • 风险几乎总是伴随着“状态”（登录态）和“动作”（写操作）而来
  • “‘网址保密’/个人使用的工具，没有攻击者注意到我”​​：​​这是一种非常有效的安全策略，称为“通过隐匿实现安全”（Security through obscurity）
  • 几个安全项检查:
    • 设置cors为二级域名, 而非CORS(app)
    • set_cookie时: secure=True,samesite=”Lax”, httponly=True, domain为.102434.xyz
    • peewee, 防sql注入
    • refresh token和access token机制: 高频使用的access token随时丢掉换新的
    • csrf -> 因为我确保无ugc内容, 所以没启用, 心智成本高/麻烦, 且各个站都没用csrf
  • XSS: crosssite scripting

现成方案

  • Auth0这类现成方案
  • supabase(firebase替代/全栈方案), firebase(重型全家桶), pocketbase(前端+go), auth.js(只对接前端), supertokens(基于java/内存开销大, 开源)
  • supabase pricing: 50k月度活跃用户
  • auth0 pricing: 25k月活跃用户
  • clerk: 10kMAU
  • auth0: b站28页结果(但很少是auth0, 精确匹配结果很少), supabase: 10页结果
    • supabase的反馈实测说开源极其糟糕/跑起来都很难, 开源只是噱头
  • “sso 开源”: 允许用户只登录一次即可访问多个应用程序或系统
    • casdoor: 轻量sso方案/1panel可直接安装
  • logto: 有中文页, 50k MAU, 1panel提供下载
    • casdoor b站搜索结果7条(1/4页), logto 2条,
  • 尝试中:
    • Auth0
    • casdoor
    • logto
  • sdk:

casdoor

  • 组织
    • 内置组织
    • 其他组织
  • 用户
  • 应用
  • 提供者
    • 多种第三方提供者
  • OIDC, OAuth, SAML
  • 不需要在你的Flask或React代码里处理用户注册、登录、修改密码这些繁琐又容易出错的事情
    • 你只需要告诉Casdoor：“嘿，我有一个应用（Application），用户在你那里登录成功后，请告诉我用户是谁就行了”
  • 前端:
    • 提供一个“登录”按钮。
    • 点击后，引导用户跳转到Casdoor的登录URL（这个URL需要用你的clientId, redirectUri等参数拼装）。
    • 提供一个 /auth/callback 页面，用于接收Casdoor返回的授权码（code）。
    • 收到code后，将其发送给你的Flask后端。
  • Casdoor的工作​​：
    • 展示登录页，处理认证逻辑。认证成功后，将用户浏览器重定向回redirectUri，并附上一个code
  • 后端（Flask）的工作​​：
    • 提供一个API接口（如 /api/login_with_casdoor）。
    • 这个接口接收前端发来的code。
    • 用这个code、你的clientId和clientSecret，​​在后端​​偷偷地向Casdoor的令牌端点（Token Endpoint）发送请求，换取最终的AccessToken和用户信息（如用户名、ID等）。
    • 这一步是关键！​​ 之所以要在后端做，是为了保护clientSecret。
    • 拿到用户信息后，你可以在Flask的Session里标记这个用户已登录，或者给你的前端签发一个你自己生成的JWT（这样你就完全掌控了JWT，而不是依赖Casdoor的JWT）
  • better auth
    • clerk
    • next-auth
    • stack auth
    • lucia auth
    • openauth
  • 组成部分:
    • verification: 验证用户是它们声称的
      • 登录: 用户名密码, passkey, oauth
      • 后续: access/refresh token
    • user info: 拿到用户的信息: 邮箱/头像/权限
    • authentication UI: 登录按钮/登出按钮
  • 新技术
    • 云托管前端: vercel
    • serverless: vercel
    • 数据库云托管: supabase
  • 关于认知的变化/后端职责:
    • 直接login_required套在所有接口上, 权限不够直接拒绝
    • 你之前用Flask做全栈时，需要处理会话（Session）、渲染模板、处理登录表单，所以感觉复杂。现在剥离了前端，后端API的世界的确就应该是这么简单
  • Google服务会关闭吗？ 会，但通常是用户数不多的边缘产品。像认证这种核心基础设施服务，被关闭的可能性极低。即使关闭，也会给出非常长的迁移周期和方案
    • ​​“新浪潮”服务（Clerk, Kinde）​​：可靠性需要评估​​：它们是VC投资的创业公司，存在理论上倒闭的风险
    • 50k MAU是什么规模？​​
      • ​​50k MAU（月活）是一个非常非常成功的个人项目/小型创业公司的规模​​。
      • 举个例子：一个50k MAU的产品，平均每天大约有 ​​1,600 - 2,000​​ 活跃用户。这已经是一个需要你开始认真考虑商业化、团队扩容和基础设施优化的阶段了。绝大多数Side Project和个人项目在整个生命周期内都达不到这个规模。
      • 因此，几乎所有认证服务的免费额度都足以覆盖你的起步和快速增长阶段，直到你的项目获得真正的成功。