#ugudango_webhooks
hearty lotusBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1226865815693955092
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
winter windBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- ugudango_webhooks, 11 minutes ago, 112 messages
- ugudango_webhooks, 2 days ago, 40 messages
amber ore
hi tarzan, I had a thread open a few minutes ago but it was closed, however the issue was not resolved.. if possible, could we loop in your colleague @nimble terrace ?
lusty crow
👋 happy to help
give me a few minutes will be back
I really need to get the context of your last conversation
amber ore
sure thing, take your time :)
additional bit of context, we're using Google Cloud, which logs the production activity and logs there but also logs the development, and while I'm not familiar with Google Cloud (i'm not the only developer), it might have something to do with changing the body, but again I'm not sure. We don't have any Cloud functions that act upon webhooks
lusty crow
are you using the same URL for both test and live mode events?
amber ore
yeah
amber ore
we're talking about the webhook endpoint URL?
lusty crow
yes
amber ore
gotcha
lusty crow
and that secret is different in the live mode webhook endpoint and the test mode one
amber ore
yeah that's correct
so theoretically if i were to remove the live mode webhook endpoint with the same URL as test mode, and then try out the test mode, it should do the trick?
lusty crow
unless you change the secret in the code it won't
the problem is that a we_xxx (Webhook endpoint) has a whsec_yyy (webhook secret)
amber ore
well the secret is the test mode secret
lusty crow
and the error is from the live mode events?
amber ore
error is from test mode events
lusty crow
the event you shared is from live mode
amber ore
sub_1P3G87FQ18ENc13dKVhZDUhF
evt_1P3G8AFQ18ENc13dB1GjNzZf*
can you check out this event?
lusty crow
both https://dev.foxyapps.com/api/webhooks and https://www.foxyapps.com/api/webhooks are failing
amber ore
correct, though dev.foxyapps isn't used anymore
lusty crow
can we cover our basis? can you double check in your code that the whsec_xxx from the screenshot is the same one on your Google Cloud function?
btw in your code are you using req.rawBody ?
amber ore
yeah, triple checked, if you see the last event the secret should end with nrW6
amber ore
btw in your code are you using `req.rawBody` ?
i am not, here'S the code
Next.js Pages router
amber ore
hmm, I'll try to do so
but this is for cloud functions, the provided code is not a cloud function
lusty crow
how so? it is
amber ore
again, not familiar with how google cloud works 😅 but the provided code is in our Next.js project, as a normal API route - In the google cloud dashboard, when i search for cloud functions, this is what i get
winter windBOT
unborn pilot
Hi there 👋 jumping in as my teammate needed to step away.
I'm catching up on the thread, and it sounds like you're running into problems verifying the signatures you're receiving in your webhook endpoints?
amber ore
hi toby, yeah that's correct
we're assuming there's something with google cloud
but can't tell exactly what the problem is :/
unborn pilot
I won't be able to comment about Google Cloud behavior. Do you think that because you had this working as expected outside of Google Cloud before?
amber ore
this was working before we switched to a new stripe account - after this, the webhooks stopped working because of the signature and the function stayed the same
google cloud was implemented before that, and it worked
unborn pilot
If you switched accounts, my suspicion is the signing secret for the webhook endpoint or the API key being used weren't updated to match those values for the new account.
unborn pilot
I wouldn't expect there to be a code or environment problem if it was working as expected before the account change, but may be mistaken.
amber ore
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=***9btq
STRIPE_SECRET_KEY=***KYUC
those are test keys (sk_test_)
unborn pilot
Hm, I'm having a hard time thinking about how you could have functioning code stop working due to switching accounts if all of the relevant account details were swapped. Are you able to log out the contents of the request body to ensure it isn't being manipulated?
amber ore
yes, here are contents:
Webhook secret: whsec_LL1EDWbQrYcjFOurIyTHec6al5ZAnrW6 Signature: t=1712574774,v1=1330bd2537550ddf84d0083ca25b84aa9754ee9cf00b0c7da5fb68ee115190b9,v0=e83b8421ce0ca1af3354cdb096a8d8ae8d9503c55b604512a420edbbb3e7ec76 Buffer: <Buffer 7b 0a 20 20 22 69 64 22 3a 20 22 65 76 74 5f 33 50 33 47 38 37 46 51 31 38 45 4e 63 31 33 64 31 44 52 54 62 65 64 35 22 2c 0a 20 20 22 6f 62 6a 65 63 ... 3526 more bytes>
Error message: No signatures found matching the expected signature for payload. Are you passing the raw request body you received from Stripe?
If a webhook request is being forwarded by a third-party tool, ensure that the exact request body, including JSON formatting and new line style, is preserved.
Learn more about webhook signing and explore webhook integration examples for various frameworks at https://github.com/stripe/stripe-node#webhook-signing
the request body is huge and I was advised not to log it but these are the bits used for constructing the event
unborn pilot
That's the whole request, but the body is the important part here. Our signature verification process is very sensitive, a change to whitespace in the body will throw it off and cause errors. Which is why I was hoping for insight on whether the request body is being manipulated in any way.
amber ore
sending request body in a second
okay, request body is undefined
tested rawBody too, same story
unborn pilot
const buf = await buffer(req);
Does this get a buffer of just the request body, or the entire request?
amber ore
the entire request
unborn pilot
That's a problem, because that's the buffer you're passing us when we're expecting just the body.
event = stripe.webhooks.constructEvent(buf, signature, webhookSecret);
amber ore
but this is the method I got from your official docs, and @nimble terrace ..
https://github.com/firstmeanseverything/firstmeanseverything.com/blob/main/pages/api/stripe/webhooks.ts - code provided by your colleague
https://github.com/stripe/stripe-node/blob/master/examples/webhook-signing/nextjs/pages/api/webhooks.ts - official stripe docs
unborn pilot
constructEvent is expecting the body of the request, if you're providing the entire request then I would anticipate you'll ecnounter. I'm not familiar with the nextjs environment specifically, but taking a glance at the code you referenced it looks like your buffer function may be different from what is shown there.
amber ore
this was covered by @nimble terrace too in a previous thread, and this is the correct setup for the buffer function since there are 2 different variants of nextjs applications
unborn pilot
Can you log buf?
amber ore
Buffer: <Buffer 7b 0a 20 20 22 69 64 22 3a 20 22 65 76 74 5f 33 50 33 47 38 37 46 51 31 38 45 4e 63 31 33 64 31 44 52 54 62 65 64 35 22 2c 0a 20 20 22 6f 62 6a 65 63 ... 3526 more bytes>
unborn pilot
Okay, so not the entire request?
amber ore
??? this is the buffer
listen if you're bot familiar with nextjs that's fine, if possible I'd try to get someone who has experience with next cause as we've seen it's pretty unique
cause we're just going in circles at this point and wasting time
this is my 3rd ticket and I've spoke to almost a dozen different people
unborn pilot
I'm sorry, I don't know what's going on in your environment which is why I'm trying to ask clarifying questions. I don't know nextjs specifically, no.
amber ore
i do not blame you nor do i blame anyone, you're as helpful as you can be :) , but let's try getting someoe who as experience with the exact framework we're using
unborn pilot
Totally fair, we don't have anyone on hand for that. You can try asking in a nextjs community where folks may be more familiar with how their request parsing works.
amber ore
i spoke with @nimble terrace , who seems to have experience with this and I'd try to get him invloved
i have to go AFK for about 15 minutes, if possible let's keep this thread open so we don't have to open another one and clutter the situation
unborn pilot
My teammate is not available right now.
amber ore
I'm not sure then what the best solution is
unborn pilot
My suggestion is to start logging what you're providing to constructEvent and ensure the request body is not being modified/manipulated before its being passed to that function. It still doesn't feel like this is a code concern though if it was working as expected for another account.
amber ore
well, we tried that too:
Webhook secret: whsec_LL1EDWbQrYcjFOurIyTHec6al5ZAnrW6
Signature: t=1712574774,v1=1330bd2537550ddf84d0083ca25b84aa9754ee9cf00b0c7da5fb68ee115190b9,v0=e83b8421ce0ca1af3354cdb096a8d8ae8d9503c55b604512a420edbbb3e7ec76
Buffer: <Buffer 7b 0a 20 20 22 69 64 22 3a 20 22 65 76 74 5f 33 50 33 47 38 37 46 51 31 38 45 4e 63 31 33 64 31 44 52 54 62 65 64 35 22 2c 0a 20 20 22 6f 62 6a 65 63 ... 3526 more bytes>
is it possible to confirm the signature is correct at least?
unborn pilot
I'm not sure I'm following, the signature we provide in the header should never be the concern.
winter windBOT
lean portal
amber ore
yeah