Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get raw request body in endpoint #831

Closed
max-niederman opened this issue Apr 2, 2021 · 6 comments · Fixed by #1109
Closed

Get raw request body in endpoint #831

max-niederman opened this issue Apr 2, 2021 · 6 comments · Fixed by #1109
Labels
feature request New feature or request
Milestone

Comments

@max-niederman
Copy link

max-niederman commented Apr 2, 2021

Is your feature request related to a problem? Please describe.
I have an endpoint in my SvelteKit app which handles webhook requests from Stripe. Each request is signed so that it can be verified to come from Stripe.

However, the code which verifies this signature needs the raw content of the message. This is a problem because the request has a content-type header of application/json, so the development server as well as a couple official adapters (notably @sveltejs/adapter-node) parses the request from JSON, preventing me from verifying the request. The other adapters either pass no body or pass the body unparsed.

Personally, it seems very weird to me that a SvelteKit application could get exactly the same request and have a totally different body passed to the underlying endpoint depending on what adapter was used.

Describe the solution you'd like
Simply put, adapters shouldn't parse the body. That code can be removed and put somewhere in the rendering process, so the raw body can be extracted by the handle or getContext hook. For ease of use, a boolean option could (and probably should) be added as either an export of the endpoint module or somewhere in the Svelte config.

Describe alternatives you've considered

  • Expose an additional property (e.g. rawBody) on the request object.
  • Remove all body parsing whatsoever.

How important is this feature to you?
I would say this issue is of moderate importance, since I can fairly easily make it work with a seperate server for the aforementioned endpoint. Every time I see it, I get a sudden, inexplicable urge to throw up, but it does work.

Additional context
The code which parses the body is here and an identical function is run in the Node adapter (for example) here.

@Conduitry
Copy link
Member

Can you use https://kit.svelte.dev/docs#hooks-getcontext to put the raw request body in the context?

@acoyfellow
Copy link

@Conduitry in my testing: it's already parsed at that point. I couldn't get the rawBody that way - I was attempting to do the same thing @max-niederman was with Stripe

@max-niederman
Copy link
Author

Can you use https://kit.svelte.dev/docs#hooks-getcontext to put the raw request body in the context?

@Conduitry No, the request is parsed before the hooks.

@babichjacob
Copy link
Member

Personally, it seems very weird to me that a SvelteKit application could get exactly the same request and have a totally different body passed to the underlying endpoint depending on what adapter was used.

To say nothing of the rest of this issue, I agree with this point and coincidentally discovered this earlier when I was looking to fix a related bug.

@babichjacob
Copy link
Member

However, the code which verifies this signature needs the raw content of the message. This is a problem because the request has a content-type header of application/json, so SvelteKit's development server as a couple official adapters parses the request from JSON, preventing me from verifying the request

It would be inefficient, but isn't it the case you can currently JSON.stringify it to bring it back to its original form to verify?

@max-niederman
Copy link
Author

It would be inefficient, but isn't it the case you can currently JSON.stringify it to bring it back to its original form to verify?

@babichjacob No that doesn't work, as the outputted JSON is formatted differently. Even if it did, it's still not really a solution since it could be prone to breakage, as well as being inefficient and confusing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants