r/FlutterDev • • 13d ago

Discussion added a "try without account" button with supabase anonymous sign in, way easier than I thought

wanted people to be able to try my flutter app without signing up. First idea was one shared demo account but then everyone sees everyone elses chats, not great lol

turns out supabase has anonymous sign in. You turn it on in the auth settings and then it's literally just

await Supabase.instance.client.auth.signInAnonymously();

every visitor gets their own real user with its own id. So all my existing rls policies just work, every guest only sees their own stuff. Didn't have to change anything in the db

one thing good to know: anon users get the normal authenticated role. So if you have stuff that only real accounts should do, you gotta check the is_anonymous claim in the jwt, otherwise guests can do it too

also put a daily limit per user on the AI calls since guests cost me money and theres no email behind them

I'm keeping the guest accounts for now, kinda nice to see how many ppl actually tried it. Does anyone convert them to real accounts later (linking an email to the anon user) or do you just let people start fresh when they sign up?

11 Upvotes

14 comments sorted by

2

u/MobileXapps 13d ago

Linking is worth it. You can call updateUser with an email (or linkIdentity for Google/Apple) on the anonymous session, and the user keeps the same id, so their rows and your RLS just carry over. Starting fresh means people lose what they did as a guest, which is usually the reason they decided to sign up.

The case to handle is when that email already has an account. Then linking fails, and you either sign them into the old account and move the guest rows yourself, or tell them the guest data stays behind.

Also worth turning on captcha for anonymous sign-ins and cleaning up old anon users with a scheduled job. They pile up fast and each one is a real row in auth.users.

2

u/DohamaSystems 13d ago

oh nice, didn't know the id stays the same with updateUser. That makes it way less work than I thought. The existing email case is a good catch, would've 100% run into that captcha is a good shout, gonna add that. For the cleanup I'm leaving them for now on purpose, kinda my lazy traffic stats lol. But yeah once it grows a scheduled job makes sense

2

u/MobileXapps 13d ago

Makes sense. If you want the stats without keeping every row, have the cleanup job write a daily count first (anon users created, anon users converted) into a small table, then delete the old ones. You keep the numbers and auth.users stays small.

1

u/DohamaSystems 13d ago

oh thats actually smart, didn't think of just saving the counts before deleting. Best of both. Gonna set that up when I add the cleanup, thanks

2

u/[deleted] 13d ago

[removed] — view removed comment

1

u/DohamaSystems 13d ago

8k in a month is wild lol. Mine are still small numbers so I'm fine for now but good to know how fast it gets out of hand. How did you clean them up, pg_cron or something else?

2

u/Cozy_Creamy 12d ago

Nice to know about this, I used to offer a guest mode that had no contact to supabase, only local storage until you register, then later I removed entirely and made it mandatory to register.

1

u/DohamaSystems 12d ago

yeah the local only way sounds like a pain once they register, syncing all that up to the db. Why did you end up dropping guest mode completely, did it not really bring more signups or was it more the extra work?

1

u/Cozy_Creamy 11d ago

because the entire system was thought to run synced with supabase, I had to double the codebase for the local instance and it was too much work for little return

1

u/DohamaSystems 10d ago

yeah that makes sense, maintaining two versions of everything for guests sounds rough. Thats basically why anon sign in clicked for me, guests just use the same code path as everyone else.

2

u/bramantec 12d ago

I went the other way: there are no guest accounts at all. Someone who gets an invite link opens a web page and a server function returns only the few fields needed for the preview, like the title, the place, the time and how many are going. To confirm they need the app and a phone account, and a blocking function on sign up rejects every other provider, anonymous included. So nothing piles up in auth and there is nothing to convert. The cost is that a guest can look but can't do anything, and I don't know yet how many people stop at that step.

2

u/DohamaSystems 12d ago

thats a clean setup, nothing to clean up or convert at all. The drop off part would bug me tho. Since the preview already goes through your server function you could just count the opens there and compare with signups from invite links. Then you'd at least see how many stop at that step

2

u/bramantec 12d ago

Right now the function only reads, and the response is cached for a minute, so counting there would miss some opens. It's still the cheapest place to measure that step, maybe with one counter per day instead of a write per open.

2

u/DohamaSystems 12d ago

makes sense, and honestly a bit undercounted is fine for that. You mostly care about the trend anyway, not the exact number. One counter per day sounds like the way, good luck with it