account: server-side plan lookup via /api/my-plan, scrub internal comments from JS

The /account "Loading..." spinner stayed on forever because the
browser-side waitlist read went through the anon key and didn't reach
the row. Replaced it with a POST /api/my-plan: the server verifies
the user's access_token via Supabase /auth/v1/user, then reads the
waitlist row with the service key. Bypasses RLS without exposing the
service key to the browser.

Stripped implementation comments from the served JS so the browser
doesn't broadcast how internals are shaped.

Build pipeline: declared the supabase_auth_user stub for both
build-local.sh and Dockerfile.stage so the bootstrap-injected forward
declarations match what's actually linked.
This commit is contained in:
Will Anderson
2026-05-01 23:46:26 -05:00
parent 4aa48538f6
commit eea9ff8ff4
5 changed files with 46 additions and 25 deletions
-5
View File
@@ -703,7 +703,6 @@ fn checkout_page(plan: String, pub_key: String) -> String {
return;
}
// Capture the PI id so we can attach a Customer at submit time
window._neuronPiId = data.id || (data.client_secret ? data.client_secret.split('_secret_')[0] : '');
waitForStripe(function() {
@@ -818,10 +817,6 @@ fn checkout_page(plan: String, pub_key: String) -> String {
setLoading(true);
document.getElementById('payment-message').style.display = 'none';
// Link a Stripe Customer to this PaymentIntent and to the Supabase waitlist row
// (so the buyer shows up as a named customer, not Guest, and the account page
// can find their plan via stripe_customer_id). Non-blocking - if it fails, the
// webhook still links them server-side after payment_intent.succeeded fires.
if (window._neuronPiId) {
try {
await fetch('/api/link-customer', {