RawPostDataException when trying to test IPN about django-paypal HOT 7 CLOSED

I just encountered the same issue and would like to share my insights and the workaround.

tl;dr django.test.Client requests default to the Content-Type=multipart/form-data, this prevents the ipn view from accessing request.body after it accesses request.POST. To work around it, pass a non-multipart content_type:

client = django.test.Client()
client.post(reverse('paypal-ipn'), data=ipn_data, content_type='application/x-www-form-urlencoded')

I found the issue encode/django-rest-framework#2774 extremely useful when debugging.

It is mentioned by Preston Holmes in a comment that Django prevents reading a body of a request with the multipart/form-data content type because "we don't want to repeat the expensive operation of parsing the multipart data".

While I'm fairly happy with the workaround, I'd hate to waste other users' time. So I would suggest we either:

1. Catch the RawPostDataException in the view (add try/except ~ L45 and present a sane error which states we expect the POST to have Content-Type: application/x-www-form-urlencoded, and it is something else).
2. Copy the request.POST/body before the first call and use the copy thereafter.

@spookylukey please let me know if you'd like to see a PR for either.

On a side note, it would be very helpful if Django docs mention the above behavior. I could not find mention of this anywhere besides this related middleware warning. Though the docstring added in this commit is very informative; I would go ahead and copy paste this directly to a warning in HttpRequest docs. I've expressed my last paragraph in this Django ticket.

from django-paypal.

You'll need to paste the complete traceback. Thanks!

I suspect you have something (e.g. middleware or custom view logic) that is reading the request data, instead of letting the ipn view do that.

You can use the PayPal sandbox and something like ngrok to test locally.

from django-paypal.

I can't do anything without a traceback, so closing. Please reopen if you can provide more information.

from django-paypal.

Given that the PayPal docs explicitly show x-www-form-urlencoded (see https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/#a-sample-ipn-message-and-response ) I think the best option here is to first check that the Content-Type matches that, and raise an exception otherwise. This avoids using internals like RawPostDataException

from django-paypal.

@spookylukey thanks for the quick response. I honestly couldn't find any mention (in quoted docs or any others) of the headers paypal sends. Right now however, the value of Content-Type is clearly x-www-form-urlencoded as can be seen by issuing a IPN Simulator request. And raising an exception if the behavior changes is a good way as any to handle this.

from django-paypal.

Is there a possibility this was changes recently? The server is getting many errors on the live server:
AssertionError: Invalid Content-Type - PayPal is only expected to use application/x-www-form-urlencoded. If using django's test Client, set content_type explicitly

from django-paypal.

@jTiKey If PayPal changed the data to no longer match what their docs show - https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/#a-sample-ipn-message-and-response - then you should take it up with them. I don't know if they have changed anything recently.

from django-paypal.