Fixes request body handling in this library

[timbastin]

Today I spend a lot of time debugging this library. The requirements I had to meet was to enable passkeys and password registration and login. I had a lot of issues because of the forwarded request body and content-type header.

Registering with a passkey resulted in a HTTP-Request originated from this library which had a Body in JSON-Format but a Content-Type Header of application/form-data. This, obviously, resulted in the ory kratos server not being able to parse the body correctly. I had to change the content-type header to application/json and the body to a stringified JSON-Object (https://github.com/ory/kratos/blob/master/selfservice/flow/registration/decoder.go#L32)[https://github.com/ory/kratos/blob/master/selfservice/flow/registration/decoder.go#L32]

I stumbled upon something which looks like a bug to me.

1. The documentation states, one should disable the body parsing https://github.com/ory/integrations/blob/main/README.md#nextjs

   import { config, createApiHandler } from "@ory/integrations/next-edge"
   
   export { config } // this line
   
   export default createApiHandler({
   /* ... */
   })

2. This is in direct contradiction to the code in the library. The createdApiHandler function stringifies the req.body (https://github.com/ory/integrations/blob/main/src/next-edge/index.ts#L115). Which is by definition undefined if the body parsing is disabled, since one has todo it manually.

   const response = await fetch(url, {
     method: req.method,
     headers,
     body:
       req.method !== "GET" && req.method !== "HEAD"
         ? JSON.stringify(req.body) // right here
         : null,
     redirect: "manual",
   })

There is a issue with quite some comments which is related to this problem: #29

The content type is zero, since the req.body is undefined. The solution to this ticket was to enable body parsing again by just stopping to export the config object. This is a workaround and not a solution to the problem: #29 (comment)

My Issue:

I did exactly like the comment asked me todo, but if you enable passkeys, you are actually supposed to send form-data and not a JSON-Object.

Since Body-Parsing is enabled again, nextjs is going to parse the form-data into a javascript object. The provided content-type header is application/form-data, which is correct. But know this library copies the application/form-data header and JSON.stringifies the request body, resulting in an invalid combination.

The fix is super simple: Just read the raw body and forward it. No json stringify. This keeps the content-type header and the body-format in sync. I think this is the intended behavior of the library, since the documentation states that the body parsing should be disabled.

[CLAassistant]

All committers have signed the CLA.

[timbastin]

Pretty related to this one: #68

Nevertheless, just sending a buffer without inspecting is more future proof in my opinion. Otherwise one could end up with a lot of ternaries.

[timbastin]

@aeneasr Reach out to me if you need help with maintaining this small library. We are using it in a big project and i am working with it on a daily basis.