Using request.POST.urlencode() to store the IPN query will cause the IPN to be marked as invalid when it goes to verify the IPN against paypal. When possible, one should use the raw_post_data instead.
preserve proper encoding so verifying the IPN does not fail
Merge remote branch 'dcramer/master'
use raw post data only if the message is not multipart
This is a major bug that causes django-paypal to fail for many non-English names. Any reason it has not been merged?
Having looked into it, it is much more complicated and tricky. Essentially, you need to send back a GET with "?cmd=_notify-validate&" + whatever_paypal_sent. However, whatever_paypal_sent can be arbitrary binary data (unicode data encoded in some arbitrary encoding, such as windows-1252). This cannot be correctly stored in a Django TextField, since it stores Unicode.
So, we've got a couple of options:
1) Find some way of storing whatever_paypal_sent in the field. That gives another problem - how do we cope with existing data in PayPalIPN.query, which has an old (broken) encoding system.
2) Instead of storing whatever_paypal_sent, use the fact that the data includes 'charset=' info to store some serialisation of the data into unicode. Then use that same charset info to convert back. This can work because the 'charset=' bit is in ASCII, so we can interpret the string as ASCII for the purposes of decoding that bit.
We also have the problem that all the tests for IPN need rewriting, since they completely bypass this issue by using Django's test Client, to which you can just pass a dictionary of data. The test client also sends data as ContentType: multipart/form-data, when I think PayPal is sending it as ContentType: x-www-form-urlencoded
I created my own pull request here: #22
I started from scratch. My patch avoids the need for two code paths added here in 3241f86 (one code path for the tests, one for real life, if I understand this correctly), because it rewrites the tests to match the way PayPal does it.
My own fix is merged now, so I'm closing this.