Bug with email addresses that use a plus sign

[BigRedBot]

Required Information

• Which language sample: php
• Mode (Sandbox/Live): Sandbox

There is a bug with email addresses that use a plus sign, and possibly other unknown circumstances.

I have a working solution with the pull request that I made: #119

But there is no way to be completely sure that it is permanently fixed unless this is fixed on PayPal's end.

[randstraw]

I will do some testing.

I think adding cmd=_notify-validate to the URL and posting $raw_post_data back directly might resolve both plus and space situations instead of creating a the string manually.

[BigRedBot]

I prefer to have it created manually because, then you know for a fact that the data is being read correctly by your script if it validates when you send it back.

Sending the raw data back would verify that you received the correct information, but it would not verify that the information was correctly decoded and understood.

[randstraw]

I meant posting back the raw data instead of creating the validation string manually, the IPN data should still be parsed and used otherwise. The validation is independent of the mechanism to resend, so if a failure happens after validation then a non HTTP 200 status could still be returned to trigger a resend.

These scripts have definitely become more community updated than others but just throwing in my 2 cents.

[BigRedBot]

But how would you know that the information you received was also decoded correctly by your script, if it is not then re-encoded and sent back for validation?

I may be wrong, but as far as I knew the script receives the data and then is supposed to send that data back to confirm that it was correctly received. What would be the harm in decoding that data and then send the re-encoded data back to verify that the data was also decoded correctly?

If I am wrong about how this works then let me know. But I thought just sending the raw data back would only verify that the correct data was received, but would not confirm that you correctly decoded the data.

I personally believe that verifying that you have decoded the data correctly is very important, because it may prevent unforeseen mistakes. And if you are decoding and re-encoding the data correctly, then this should not be a problem to get it verified this way anyway. The only problem would be if you are not correctly decoding the data, and that could cause problems regardless.

[randstraw]

The primary intent of verification is ensure the data was sent by PayPal.

What you say also makes sense as far as encoding and decoding, but then exceptions for fields are being added to the validation request process such as the dates or email addresses, which may have been correctly decoded for your system anyways. I was suggesting a way to maybe not need to do this at least for verification purposes.

Again simply just a suggestion, prior to seeing how Webhooks are validated I would have went decoding and encoding but now my philosophy on such things are more send the raw stuff to validate then after that is successful format it to your needs.

[UCIS]

@pp-randy I think posting the raw data back to PayPal should be safe. It does eliminate possible "corruption" caused by incorrect decoding or unintentional reordering. It's safe provided that the decoding code is valid (which it currently is not).

@BigRedBot

• The patched version modifies/pollutes the global $_POST variable, which the original code did not do. It's just example code, but since it's written as a reuseable class it might be better to not touch $_POST.
• The patch makes an exception for e-mail addresses based on their content (which IMO is bad), and drops the exception for dates. Why not just use urldecode for ALL variables? If PayPal's encoding is consistent that seems to be the only right thing to do.

Also the check for magic quotes is wrong. Since the data is decoded using rawurldecode, it is NOT affected by magic quotes so using stripslashes may actually corrupt the data.

(Edited) Tests with the staging environment show that the + sign in at least the product_description field is properly encoded and the + sign is actually used to encode spaces. Still hoping the encoding is the same for all fields and also on production, this would mean that urldecode, parse_url or just $_POST would be the right thing to use.

[BigRedBot]

I modified the original post to include this pull request: #119