Difficulty Syncing Stripe with Supabase using subscription-starter Vercel Next.js Template

[kola-white]

Question to the Supabase Github support community:

Hello Supabase community,

I was advised by Supabase support to post my issue here. Please read on...

I'm working with the subscription-starter Vercel Next.js template, incorporating the Flowbite-react plugin and Stripe integration. I've set up Stripe's no-code pricing table and checkout session/billing options. While I can confirm that my webhook handler functions as expected (the logs on my Stripe dashboard are showing all the events I'm looking to capture), I'm facing difficulties getting Supabase to synchronize with Stripe.

Some more context:

• The browser cookie in my application appears to refresh correctly with the expected tokenization, following Supabase documentation guidelines.
• Vercel logs are registering the information correctly without any errors.
• My schema.SQL is properly configured, and both types_db and types are in good order.
• My Supabase tables are set up correctly, with all RLS policies in place, except for the 'customer' table, as recommended by Supabase.

Given all these configurations and checks, can anyone help shed light on why I might be experiencing this syncing issue between Supabase and Stripe?

Thank you in advance for your assistance!

[jmsbooth]

Running into a similar issue. Followed the deployment instructions in the repo and the stripe products are not populating in the Vercel deployment nor in the Supabase tables.

One note that I found is that the "Deploy with Vercel" option creates the env. vars using the LIVE Stripe deployment, but the instructions say to use the TEST "STRIPE_WEBHOOK_SECRET" key. Tried every combination and couldnt get the information to populate.

Redeployed the app after every change, updated the Stripe products, ensured Vercel and Supabase were connected, turned off RLS on Supabase. Nothing Ive tried worked.

[nathanjhood]

Hi everyone.

One note that I found is that the "Deploy with Vercel" option creates the env. vars using the LIVE Stripe deployment, but the instructions say to use the TEST "STRIPE_WEBHOOK_SECRET" key. Tried every combination and couldnt get the information to populate.

Just to say that I do believe the env vars are incorrectly configured at present, as outlined here. I had clone-deployed the nextjs subscription starter, had issues getting Stripe to populate the tables in Supabase, then decided to take a break. Unfortunately unbeknownst to me in that moment, was that my domain was under a rampant ddos attack all weekend long (and probably more).

From what I can tell of my logs, the attacker may have exposed some of my API keys. Without giving out info that could be misused, it seemed as simple as navigating to a URL on the running instance of the one-click-deploy example, and reading the .js right there in the browser (can provide more info privately if required).

Unfortunately the attacker wasn't quite able to get the tables to populate either, before I changed the keys :)

Just wanted to add some very serious concerns about the safety of the current example.

[Innders]

@nathanjhood any updates on these security issues you found? I have deployed using the one click deployment on Vercel and everything is working with Stripe webhooks populating the tables correctly but still concerned.

[nathanjhood]

@nathanjhood any updates on these security issues you found? I have deployed using the one click deployment on Vercel and everything is working with Stripe webhooks populating the tables correctly but still concerned.

Hi, thanks for asking! Sorry if my message was unclear, it was a highly stressful incident and I didn't have much time to understand the issue, nor better verbalize it...

tl;dr - keep a close eye on all the logging/reporting you have available in both Vercel and Supabase. Also, if your repo is public, check the 'insights > traffic' tab for high numbers of visitors, clones, etc. Don't test your payments page with Docker. If your deployment is live, check the related search results in a search engine.

For the record - though I'm not sure this is supposed to be discussed on a public forum - my Vercel deployment logs were showing me that someone was frantically calling http requests (GET/OPTIONS, etc) on the outputted "chunks/\<string>.js" files on my deployment. The request body being sent was well-constructed but incomplete - I noticed that my test publishable key was right there in the request body, in my vercel logs; the server was responding appropriately to these requests, but they were not being triggered by me.

At some point, I Google-searched my site just checking SEO, and realized that all of the related searches were for "supabase standard library", "IP address StoneyDSP Spain", "Ubuntu desktop source code", and so forth (shown below)...

I deleted the entire repo, deployment, even the sub-domain that I had used for the task.

FWIW I also had a github-readme-stats instance deployed on a connected page, using a personal GitHub access token; this was also getting hammered with similar GET requests.

After removing both, the weird logging behaviour migrated over to my supabase project instead. Supabase Support - who are excellent - helped me ensure that I've got the right tables locked in with RLS, and there are no cricks in my code. Somebody has been trying relentlessly (about 3 times per second) to access my users table ever since, to no avail.

I firmly recommend implementing the NextJS middleware and Auth Provider flow, in case you do encounter bothersome logs/visitor activity. I'm currently redirecting all un-authenticated traffic straight to the login page until I decide to launch publicly. In any case, I can console.log IP's, user agents, and so forth meanwhile, thanks to the middleware. You can check my current implementation (per the docs) on my production branch.

RE: Populating the tables - make sure you have the Foreign Data Wrapper extension installed and configured to import the Stripe data as a postgres-friendly table. I believe it's in the example, but easily missed when building manually.

Best, Nathan.

EDIT: Guess they saw this post...

[kola-white]

@nathanjhood RE: Populating the tables. Apologies for my delayed response. I've successfully set up the Stripe FDW, and I'm genuinely grateful to see the foreign table populating with Stripe data. It feels like magic! ✨

Hello again! 🌟

I've run into a little hiccup, and I'm hoping @nathanjhood or someone else here can shine some light on the matter.

Issue: When attempting to query the stripe_customers foreign table, I'm encountering an error mentioning the rowid_column. The error is as follows:

ERROR: option 'rowid_column' is required

Background:

• I've set up the Stripe FDW via the Supabase dashboard.
• The foreign tables (like stripe_customers, stripe_products, etc.) read and populate all incoming Stripe data as expected.
• The issue arises when I try querying these tables using a database tool or even the Supabase SQL editor.

What I've Tried:

• I attempted to set the rowid_column option as 'id' based on the assumption that the id column from Stripe's data serves a unique identifier purpose. However, this resulted in an error indicating that the option rowid_column was not found.

Additional Context: After some investigation and understanding SQLite's ROWID concept, it seems like the id column from Stripe might serve a similar unique identifier purpose for each row. But I understand SQLite and PostgreSQL are different systems, and I might be missing a piece of the puzzle here.

I'm sure I'm not the only one who's ventured into the Stripe FDW territory, so if anyone has faced a similar issue or has insights to share, it'd be greatly appreciated! 🙏

Once again, a big thank you to this community of like-minded developers. Your hard work, shared knowledge, and collaboration are what make projects like Supabase possible and thrive.

Looking forward to hearing from you!

Warm regards,

Nick

[nathanjhood]

@nathanjhood RE: Populating the tables. Apologies for my delayed response. I've successfully set up the Stripe FDW, and I'm genuinely grateful to see the foreign table populating with Stripe data. It feels like magic! ✨

Hello again! 🌟

I've run into a little hiccup, and I'm hoping @nathanjhood or someone else here can shine some light on the matter.

...

Warm regards,

Nick

Hey, so glad my snippet of advice was helpful for you!

I wish I could help further, but unfortunately my Supabase project just ground to a halt this morning; apparently I've used up my Edge functions quota for the free trial plan. It's strange because I've not worked on the project for a few days, my deployment had 8 unique visitors this week, and yet my Supabase logs have not stopped reporting GET requests in /auth/v1/usersand so forth.

Unfortunately I can't even log in to my own test user account on my site when running a on local dev server right now. So I'll probably have to remove Supabase entirely from my NextJS project, assuming support still has no further advice on the matter (besides going premium).

In lieu of anything more helpful, I can point to the docs here and hope you're able to it figured out. Let us know if you do!

[chriscarrollsmith]

Hi everyone.

One note that I found is that the "Deploy with Vercel" option creates the env. vars using the LIVE Stripe deployment, but the instructions say to use the TEST "STRIPE_WEBHOOK_SECRET" key. Tried every combination and couldnt get the information to populate.

Just to say that I do believe the env vars are incorrectly configured at present, as outlined here. I had clone-deployed the nextjs subscription starter, had issues getting Stripe to populate the tables in Supabase, then decided to take a break. Unfortunately unbeknownst to me in that moment, was that my domain was under a rampant ddos attack all weekend long (and probably more).

From what I can tell of my logs, the attacker may have exposed some of my API keys. Without giving out info that could be misused, it seemed as simple as navigating to a URL on the running instance of the one-click-deploy example, and reading the .js right there in the browser (can provide more info privately if required).

Unfortunately the attacker wasn't quite able to get the tables to populate either, before I changed the keys :)

Just wanted to add some very serious concerns about the safety of the current example.

Hi. I'd like to see if I can fix this in the template. Can you DM me info about where you found your API keys exposed?

[nathanjhood]

Hi. I'd like to see if I can fix this in the template. Can you DM me info about where you found your API keys exposed?

Hi, yes I'd be happy to help. Could you please let me know via which channel I can DM you?

[chriscarrollsmith]

Hit me here on LinkedIn:

https://www.linkedin.com/in/chriscarrollsmith

Or Twitter:

https://twitter.com/christophcsmith

[nathanjhood]

By way of a small update from my end; life has been peachy since migrating all of my supabase clients over to @supabase/ssr - which I believe is coming out of beta slated for release in the coming launch week.

The client design pattern is quite straightforward - here are the official examples for various handlers.

Hit me here on LinkedIn:

https://www.linkedin.com/in/chriscarrollsmith

Or Twitter:

https://twitter.com/christophcsmith

Thanks, I sent a request to connect on LinkedIn!

[chriscarrollsmith]

Okay, excellent. Hopefully that means we've already got this resolved in our open PR for SSR.

On Sun, Dec 10, 2023, 9:06 AM Nathan @.***> wrote:

By way of a small update from my end; life has been peachy since migrating all of my supabase clients over to @supabase/ssr - which I believe is coming out of beta slated for release in the coming launch week.

The client design pattern is quite straightforward - here are the official examples for various handlers https://supabase.com/docs/guides/auth/server-side/creating-a-client.

Hit me here on LinkedIn:

https://www.linkedin.com/in/chriscarrollsmith

Or Twitter:

https://twitter.com/christophcsmith

Thanks, I sent a request to connect on LinkedIn!

— Reply to this email directly, view it on GitHub https://github.com/vercel/nextjs-subscription-payments/issues/247#issuecomment-1848975354, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASCYPGOTFBYA7SI3CFM4ERDYIW6WTAVCNFSM6AAAAAA5ALMS5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYHE3TKMZVGQ . You are receiving this because you commented.Message ID: @.***>

[chriscarrollsmith]

I believe this issue is resolved and can be closed.