#89 — Check options to go public with white list of emails

Repo: Twill-AI/facade State: closed | Status: done Assignee: Unassigned

Created: 2024-08-29 · Updated: 2025-09-15

Description

Caused by https://twill-network.slack.com/archives/C06UCQP1BFC/p1724952079704339 For October release we should have in ability to prevent access of “anyone” to Twill AI except list of email addresses handpicked by Michael.

Expect users to don’t have the same email domain.

AC:

  • Investigate options to allow access to only users with specified emails. Provide it to the team as a table with an effort estimate and pros/cons.

Investigation details

Raw options:

  1. Hardcode list of allowed emails in front-end. Pros - the most lightweight approach. Cons - insecure because it may be bypassed from the client side.
  2. Hardcode list of allowed emails in Facade’s code or in configuration. Don’t allow create tenants if user’s email doesn’t exist in while list. Pros - easiest to implement. Cons - 1) Supabase Auth may grow a lot with users which signup-ed but can’t pass further; 2) requires some effort devs to update the list.
  3. Use db triggers or PostgreSQL RLS (idea from Supabase’s Open-yet issue and even explained in YouTube stream during 7+ minutes). Pros - 1) managed from db side; 2) theoretically we may show to Michael how to change list of emails in Supabase UI. Cons - 1) we don’t have RLS enabled; 2) managing triggers in Supabase-managed tables may be dangerous; 3) requires decent devs effort to implement everything in db and explain how to change emails list.
  4. Disable all

Notes

Add implementation notes, blockers, and context here

Add wikilinks to related people, meetings, or other tickets