Skip to content

Latest commit

 

History

History
47 lines (30 loc) · 1.35 KB

File metadata and controls

47 lines (30 loc) · 1.35 KB

WeChat Login Phase 2 Notes

Current recommendation

Phase 1 keeps authentication simple:

  • Supabase Auth
  • email OTP
  • the same profiles, properties, destinations tables

This already solves long-term storage and cross-platform sync.

Why WeChat login is harder

For this project, WeChat login is not just a UI button. It usually requires:

  • a WeChat Open Platform application
  • callback domain configuration
  • an auth bridge that exchanges WeChat identity for a Supabase session

Supabase can remain the source of truth for user sessions, but WeChat often needs a custom bridge layer.

Recommended phase 2 architecture

  1. User clicks 微信登录
  2. Frontend opens WeChat OAuth
  3. WeChat redirects back with code
  4. Edge Function or tiny backend exchanges code for WeChat user identity
  5. Bridge creates or maps a Supabase user
  6. Frontend receives a Supabase session

Complexity assessment

  • Web H5 WeChat login: medium
  • WeChat mini program login: medium-high
  • Supporting both H5 and mini program together: high

Important constraint

Do not redesign the data tables for WeChat login.

The current phase 1 schema is already compatible:

  • profiles.id stays mapped to Supabase auth user id
  • properties.user_id and destinations.user_id remain unchanged

That means phase 2 only changes the authentication entrypoint, not the storage model.