Webhook plug fails in local environment after reading request headers

[soyondori]

Existing Issue or Pull Request Verification

• [X] Confirmed, no existing Issues or Pull Requests found related to my submission.

Package Version

3.2.0

Are you using the latest version?

• [X] Yes, I verified the issue is still present in the latest version.

Steps to Reproduce

I'm encountering an issue where Stripe webhooks are failing in my local environment but weirdly they are working fine in production. The webhooks are forwarded through the Stripe CLI using the listen command.

Environment

Bandit version: 1.5.7 Phoenix version: 1.7.14 Elixir version: 1.16.1 Stripe API version: 2024-04-10

Plug Config

  plug Stripe.WebhookPlug,
     at: "/webhooks/stripe",
     handler: MyApp.WebHooks.StripeHandler,
     secret: {Application, :get_env, [:stripity_stripe, :webhook_secret]}

Handler

defmodule MyApp.WebHooks.StripeHandler do
  require Logger
  @behaviour Stripe.WebhookHandler

  @impl true
  def handle_event(%Stripe.Event{
        type: "checkout.session.completed",
        data: %{object: session}
      }) do

     IO.inspect(session)
    :ok
  end
end

Stripe CLI Commad

stripe listen --forward-to localhost:4000/webhooks/stripe

Expected Result

I'd expect to receive the events without any trouble.

Actual Result

I get the following error:

[error] ** (Bandit.HTTPError) Request line HTTP error: ",\n"
    (bandit 1.5.7) lib/bandit/http1/socket.ex:420: Bandit.HTTPTransport.Bandit.HTTP1.Socket.request_error!/2
    (bandit 1.5.7) lib/bandit/http1/socket.ex:50: Bandit.HTTPTransport.Bandit.HTTP1.Socket.read_headers/1
    (bandit 1.5.7) lib/bandit/pipeline.ex:29: Bandit.Pipeline.run/4
    (bandit 1.5.7) lib/bandit/http1/handler.ex:12: Bandit.HTTP1.Handler.handle_data/3
    (bandit 1.5.7) lib/bandit/delegating_handler.ex:18: Bandit.DelegatingHandler.handle_data/3
    (bandit 1.5.7) /Users/silmood/Documents/Development/chain/chain/deps/thousand_island/lib/thousand_island/handler.ex:379: Bandit.DelegatingHandler.handle_info/2
    (stdlib 5.2) gen_server.erl:1095: :gen_server.try_handle_info/3
    (stdlib 5.2) gen_server.erl:1183: :gen_server.handle_msg/6
    (stdlib 5.2) proc_lib.erl:241: :proc_lib.init_p_do_apply/3

I inspected the headers and the JSON payload of the webhook, and everything seems correct:

POST /webhooks/stripe HTTP/1.1
Host: localhost:4000
User-Agent: Stripe/1.0 (+https://stripe.com/docs/webhooks)
Content-Length: 3384
Accept: */*; q=0.5, application/xml
Cache-Control: no-cache
Content-Type: application/json; charset=utf-8
Stripe-Signature: t=1726116920,v1=cde87694522c7c716fce486f68e3b258b1f9cb9f32b06d1e263274a0e9302d38,v0=4520dc1ca451ba2e9f72407a77af39dc3a18df3cdc35426110d0917f064395d7
Accept-Encoding: gzip

Here is a part of the JSON payload being sent by Stripe:

{
  "id": "evt_1Py53s4C8bZ1vpUVJrbs2C8I",
  "object": "event",
  "type": "checkout.session.completed",
  "data": {
    "object": {
      "id": "cs_test_a1pGjiUDYozyctsMbmTQJAIuaHPc9WRgulEMxIqoIfOr5u9rxUSczEtIH3",
      "object": "checkout.session",
      "amount_total": 80000,
      "payment_status": "paid",
      "currency": "mxn"
    }
  },
  "livemode": false
}

Additional Information:

• 🛑 I attempted to switch from Bandit to Cowboy in the phoenix adapter, but the webhook still failed with a 400 status code.

• ✅ I configured a standard Phoenix endpoint to handle the webhook (instead of using the Stripity Stripe plug), and in this case, the webhook was successfully received.

• As weird as it sounds, this problem is not happening in my prod environment even when I'm using the same deps versions and the same stripe api version.

[yordis]

It seems that is related to Bandit; which I havent use it myself, I am on vacation until Sep 25th, so I am not able to help here until then.

Please create a PR if possible.

[github-actions[bot]]

This issue has been automatically marked as "stale:discard". We are sorry that we haven't been able to prioritize it yet. If this issue still relevant, please leave any comment if you have any new additional information that helps to solve this issue. We encourage you to create a pull request, if you can. We are happy to help you with that.

[github-actions[bot]]

Closing this issue after a prolonged period of inactivity. If this issue is still relevant, feel free to re-open the issue. Thank you!