Tutorial · 3 minutes
Add Google sign-in
to your Adorie site
Let visitors create accounts on your site using their Google login. OAuth is fully pre-configured by Adorie — no Google Cloud project, no API keys, no client secrets. Just toggle & ask the AI for a sign-in button.
✨ ZERO CONFIG — POWERED BY ADORIE
adorie.app/projects/…
Welcome
Members-only content inside
Live · my-site.adorie.app
Visitor Sign-In
Enable Google sign-in for site visitors
Visitors can create accounts using Google. Powered by Adorie — no setup required.
After enabling, ask the AI to "add a Google sign-in button" in your next chat.
My site
add a Google sign-in button in the top right of the nav
Adding Google sign-in now — visitors will be able to sign in with their Google account in one tap 🔐
my-site
Menu
About
Sign in
Welcome
Sign in to see members-only content.
Google
Choose an account
to continue to my-site.adorie.app
J
Jordan Lee
jordan@example.com
Welcome, Jordan! ✨
Members-only content unlocked
Step 1 of 4
Verify Visitor Sign-In is enabled
Open your project, tap Publish, find the Visitor Sign-In section. The checkbox is on by default. Leave it on.
Step-by-step
Four steps. The third is the only one that costs a credit.
1
Open Publish & verify Visitor Sign-In
From your project, tap Publish (top-right). Scroll to Visitor Sign-In. The toggle "Enable Google sign-in for site visitors" is on by default — leave it on.
2
Ask the AI for a sign-in button
In the chat, send: "add a Google sign-in button". Be specific about placement if you want — e.g. "add a Sign-in button to the top-right of the nav".
3
Watch the preview update
Adorie wires up the Google OAuth flow using the shared Adorie Guest Mode backend. The button appears in the preview. Click Publish when you're happy.
4
Test on the live URL
Open your published site (e.g. my-site.adorie.app) and click Sign in. Google's account-picker opens → choose an account → you're back, signed in.
✨ Why no setup is needed
Most platforms make you create a Google Cloud project, register an OAuth client, configure redirect URIs, and store the client secret. Adorie does all of that once for the whole platform and reuses it across every published Adorie site.
No Google Cloud account required.
No OAuth client to configure or rotate.
No client secret to keep out of frontend code.
No redirect URI list to maintain when you change domains.
🔒 What about the privacy/branding tradeoff? The Google account-picker says "to continue to your-subdomain.adorie.app", not "Adorie" itself. Visitor accounts and data are scoped to your project — other Adorie sites can't see them.
What the AI builds for you
Ask in plain English. Adorie scaffolds the OAuth dance, session handling, and UI.
🔘
"Sign in with Google" button
Standard Google branding (the four-color G icon, neutral-grey button). Triggers signInWithOAuth({ provider: 'google' }) against Adorie's shared Supabase.
👤
Signed-in user state
Once signed in, Adorie surfaces the user's name + avatar (from Google profile). The AI can swap the Sign-in button for a user pill on request.
🚪
Sign-out
Ask "add a sign-out button". Adorie calls signOut() and clears the session. Browser refresh shows the unauthenticated state.
🔐
Members-only content
Ask "hide the pricing table unless signed in". The AI gates whichever section you name behind the auth state.
💾
Per-user data persistence
Need to save visitor input (favorites, drafts, settings)? Ask "save the user's todo list to their account". Adorie writes to the site_data table, auto-scoped to (project_id, user_id).
🪞
Profile-page scaffolding
Ask "add a profile page that shows the user's photo and email". Adorie reads from the Supabase user object — no extra database needed.
Prompts that work well
Treat the sign-in as a feature you describe, not code you write.
Basic
Add the button.
"add a Google sign-in button to the top-right of the nav"
Gate
Hide a section unless signed in.
"hide the entire menu section unless the visitor is signed in — show a sign-in prompt instead"
Persist
Save data tied to the user.
"let signed-in users mark items as favorites — save the list per user so it persists when they come back"
Profile
Surface who's signed in.
"after sign-in, show the user's profile photo and name in the nav, and replace the Sign-in button with a Sign-out option"
💾 Storing per-user data — the site_data table
Adorie ships a shared site_data JSONB table. Every row is auto-scoped to (adorie_project_id, user_id), so user A on your site can never see user B's data, and neither can users from other Adorie sites.
The AI knows how to use it — typical generated patterns:
// Insert / update
await _gsb.from('site_data').upsert({
adorie_project_id: 'YOUR_PROJECT_ID',
user_id: user.id,
key: 'favorites',
value: ['item-1', 'item-2'],
});
// Read back
const { data } = await _gsb.from('site_data')
.select('value')
.eq('adorie_project_id', 'YOUR_PROJECT_ID')
.eq('user_id', user.id)
.eq('key', 'favorites')
.single();
You don't have to write this — describe the behavior and Adorie produces it. The code above is just so you know what's happening under the hood.
🔒 RLS is enforced server-side. Even if visitors poke around the JS, Supabase Row-Level Security blocks cross-user access at the database level.
🧪 Testing checklist
1. Publish first. Google's OAuth redirect doesn't work in iframe previews — you'll see "🔒 Google sign-in works on your published site. Click Publish to test it live." in the preview if you try. Hit Publish and test on the live URL.
2. Open the live URL in a regular tab (not the builder iframe). Click the Sign-in button — Google's account-picker should open.
3. Pick a Google account. First time on a new project you'll see a consent screen mentioning your subdomain as the destination. Click Continue.
4. Confirm you land back signed in. The page reloads and the UI should reflect the authenticated state.
5. Hard-refresh and check persistence. Close the tab, reopen the live URL — the user should still be signed in (session stored in localStorage).
⚠️ "Sign-in popup blocked" on Safari? Safari sometimes blocks OAuth popups from non-user-initiated calls. Make sure the sign-in action is wired directly to a button onclick — Adorie's default does this, but if you've heavily customized the flow, ask the AI to "trigger sign-in directly from the button click, not async".
🌐 Using a custom domain?
If you've connected yourbrand.com via the custom domain tutorial, Google sign-in keeps working automatically — Adorie's shared OAuth config covers all *.adorie.app subdomains and any custom domain pointed at Adorie via the standard DNS records.
The account-picker will show yourbrand.com as the destination once DNS + SSL have propagated.
🛑 Turning it off
If you change your mind: go back to Publish → Visitor Sign-In and uncheck the toggle. Any sign-in button code the AI already generated will still be in your HTML — ask the AI to "remove the sign-in button" to clean that up. Existing user records in site_data stay until you delete the project.