Closed mitjans closed 5 months ago
Thanks again @mitjans ! That sounds like a good feature to add in my opinion. Let me see how we can do it and if we feel we simplify the user experience this way
🔥 ❤️
After looking at it I am wondering if its something that make sense to have. As you said it creates maybe unecessary complexities for 4 line of codes.
I was thinking of an implementation like this.
in nuxt config
webhooks: [
{
name: "all",
secret: "whsec_..."
},
{
name: "customer.subscription.created",
secret: "whsec_...",
}
]
}
The all is the default and will be choosen for all not found.
So we would create a composable as you have done and folllow this code from stripe examples
https://github.com/stripe-samples/checkout-single-subscription/blob/main/server/node/server.js
The problem I am seeing with this and user can encounter is. They wanted to define a pair webhook secrets but they will endup with the default secret and will at this point with an error I guess ? But they will have hard time debugging it.
Thats why here I am feeling maybe this is not what we should do what do you think @fuentesloic @mitjans ?
I agree the implementation is not as frictionless as I would like it to be.
I was thinking that maybe the error thrown by stripe when using an invalid secret is self-explanatory, something like: "You are using a webhook for another endpoint". Something that would give a hint to the developer that it's using an invalid webhook.
If I'm not mistaken, each webhook secret maps to an endpoint. It would be super nice to have that mapping done internally and make it type-safe, although I'm afraid that's really difficult to accomplish.
Either way, it would be nice if the module would provide some examples of how to use webhook secrets, even if it doesn't handle them internally.
For the examples definitely agree yeah. I am looking for it but need to know if we can make service key and webhook secret restricted to pass it inside the example pr I have created so people can't break everything but can run the playground and it just works.
If you have any hint how we can scope a key don't hesitate to tell. I will try to spend some time on the doc tonight
Closing this one for now
It would be awesome to include functionality to handle webhook secrets as well. More information about Stripe Webhook secrets can be found in Stripe's Documentation.
I don't know what would be the correct approach here. Possible solutions:
Get the Webhook secret from the environment. In that case, no changes should be done to this module (this is how we are handling it right now):
Another possible solution would be to provide Webhood secrets to this module (through Nuxt/Env) and create a new function that validates a webhook request. Something like this:
Internally, this function should:
stripe-signature
headerconstructEvent
I don't know what would be the implications of that. For example, what happens if the user has created more than one webhook, each one of them with a different webhook secret? How would that be handled internally?