PalPAL sandbox IPN processor rejecting all messages? - paypal

I was using the PalPal IPN simulator all day without problems, and at some point I got kicked out and the developer portal got upgrade.
Picking up right where I left off, I'm now receiving IPN messages from the sandbox, but attempts to validate the message return 400 Bad Request.
Now before you go saying "Oh, you just need to do HTTP/1.1 and send the Host:" field, I'm already doing that (and have been for months).
Request body:
POST /cgi-bin/webscr HTTP/1.1
Host: www.sandbox.paypal.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 1008
Connection: Close
Response body:
HTTP/1.1 400 Bad Request
Date: Sat, 09 Mar 2013 00:07:26 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Set-Cookie: c9MWDuvPtT9GIMyPc3jwol1VSlO=%7chl7gnTEYtJzNIfLXr3W6GtWjMBrl6ln8aFetxEss8pSDsWPDwv59RMYj7ONKH0013betZW%7cnf1wC_g4C0pER3V0XtOw2969OSDVwC24TgW3akpoK6QHdkz0_7G0YdJ9Cnjz-JKZbESVG0%7c; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: cookie_check=yes; expires=Tue, 07-Mar-2023 00:07:26 GMT; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: Apache=10.72.109.11.1362787646017906; path=/; expires=Mon, 02-Mar-43 00:07:26 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain; charset=ISO-8859-1
It it just me, or is the portal broken?

You're correct. The ability to verify IPNs in sandbox is broken at the moment. We're currently working to fix the issue now and I'll be sure to update you once we have an update.
Please let me know if you are experiencing any other issues with the developer/sandbox environment and I'll be sure to follow up.

Related

UnparseableJsonResponse: API Version 1

My first app for Google Home has just been released, but it's in the "unhealthy" status.
Looking at the logs, I see that the response received is :
Received response from agent with body: HTTP/1.1 200 OK
Date: Thu, 01 Mar 2018 16:36:44 GMT
Content-Type: application/json
Content-Length: 174
Connection: keep-alive
Cache-Control: private, must-revalidate
Google-Actions-API-Version: 2
expires: -1
Vary: Accept-Encoding
Content-Encoding: gzip
Accept-Ranges: bytes
X-Cache: MISS
{"expectUserResponse":false,"finalResponse":{"richResponse":{"items":[{"simpleResponse":{"ssml":"<speak>This is AppBundle\\ActionsOnGoogle\\DictionaryEndpoint</speak>","displayText":"This is AppBundle\\ActionsOnGoogle\\DictionaryEndpoint"}}]}}}.
and yet I have "UnparseableJsonResponse: API Version 1: Failed to parse JSON response string with error"
I can't understand what's wrong with health probe :
My Google Home work fine (conversations are okay)
It works fine in the simulator too
API version in response is "2" not "1"
JSon response is valide
Anyone can help ?
Thanks
Frederic

Fetch Google sees 301 redirect

Background info: Some of my website innerpages had malware on it last week. The whole site has been reset, updated en cleared from malware a couple days ago. The website is SE optimized, but not spammed at all.
Q: Some innerpages of the website have suddenly dropped from the Google results.
Searching site: http://www.domain.com/innerpage doesn't even give a result.
Searching cache: http://www.domain.com/innerpage has no results since today
Webmaster page error: The page seems to redirect to itself. This may result in an infinite redirect loop. Please check the Help Center article about redirects.
HTTP/1.1 301 Moved Permanently
Date: Mon, 28 Oct 2013 20:15:18 GMT
Server: Apache
X-Powered-By: PHP/5.3.21
Set-Cookie: PHPSESSID=170fc3f0740f2eb26ed661493992843a; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: http://www.domain.com/xmlrpc.php
Location: http://www.domain.com/innerpage/
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
The .htaccess file looks fine too. Do you guys have any idea what going on here?
The page is w3c valid and even online googlebot simulators show state 200 OK.

IPN PAYPAL - Invalid Tests

Currently, I test the paypal transaction via the wordpress plugin eshop. Everything works fine between my test website and the Paypal Sandbox. I received the amount of each transaction on my test paypal account.
So, is there anybody to explain why, in my IPN log, I saw this kind of message?
[09/16/2013 12:17 PM] - FAIL: IPN Validation Failed.
IPN POST Vars from Paypal:
IPN Response from Paypal Server:
HTTP/1.1 200 OK
Date: Mon, 16 Sep 2013 12:17:12 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Set-Cookie: c9MWDuvPtT9GIMyPc3jwol1VSlO=44VS0oE0w9OKqQXm8_tt1vtbJvdnyOujOdaUKmL1YKFVv2fNtrpwZwLBrbXK2cj1hl4rsZsNkbdK1rYEiWVjJVoDpdtpsQU3C9TlmnyeNPuIQIGzN5pnm1txc-zdooQbYBGoEe_cDYBNgIPU16TPpvtCYBTcLZ720155oY1ososuqpBRYu-KcG2qifDzzMkZVDADM6CZu3SSvGklgKgVOqxIb15FtRPLMepSn0re190FNP-12fh8TcLc44kBTBja1ZPI__GWGtkVWAweinGCtdtky6ebYrHqjZvD0dtsfoMyhx0XE07tPXfKL2FmQMUnE7ghjcySUFuCTVjZfcNiDGcCkn9EaQZ-DvIhL8X4aT6c1FvqNR3vjnRokP6neuGRAiu9hpn6Br7sp4UJhU3pEaoRK2G76FC1x6dBXTtX-7qud2MV_IGGom_q8Li; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: cookie_check=yes; expires=Thu, 14-Sep-2023 12:17:12 GMT; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: navcmd=_notify-validate; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: navlns=0.0; expires=Sun, 11-Sep-2033 12:17:12 GMT; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: Apache=10.72.109.11.1379333832493873; path=/; expires=Wed, 09-Sep-43 12:17:12 GMT
Connection: close
Set-Cookie: X-PP-SILOVER=name%3DSANDBOX3.WEB.1%26silo_version%3D880%26app%3Dslingshot%26TIME%3D3371578962; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: X-PP-SILOVER=; Expires=Thu, 01 Jan 1970 00:00:01 GMT
Set-Cookie: Apache=10.72.128.11.1379333832485619; path=/; expires=Wed, 09-Sep-43 12:17:12 GMT
Vary: Accept-Encoding
Strict-Transport-Security: max-age=14400
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
7
INVALID
0
Thanks a lot for your help.
The data being sent back to PayPal must not match what PayPal originally sent. When this happens they won't verify it.
Make sure that if you're using the sandbox for the purchase you're also hitting the PayPal sandbox for IPN verification and visa versa. Also, make sure you've got all of the original data included just as it was sent to you.

Facebook RSS feeds ignoring HTTP ACCEPT header elements?

FB doesn't seem to respect ACCEPT headers sent to /feeds/page.php. See below example:
GET /feeds/page.php?id=10036618151&format=rss20 HTTP/1.1
Connection: Keep-Alive
**Accept: text/xml,application/xml**
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: www.facebook.com
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, must-revalidate
**Content-type: application/rss+xml**
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Last-Modified: Wed, 08 Feb 2012 10:05:49 -0800
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Set-Cookie: datr=-vIzT4cxw52hjjqTfrpQkNYX; expires=Sat, 08-Feb-2014 16:23:22 GMT;path=/; domain=.facebook.com; httponly
X-FB-Debug: qx/SiyRZDiVPm4wfiKVj37HImPoKM+DVAsO4oKSbSr0=
X-Cnection: close
Date: Thu, 09 Feb 2012 16:23:22 GMT
Content-Length: 41236
I cannot seem to find a way to post a new bug report on http://developers.facebook.com/bugs, as I don't have the "Create" (nor the "Subscribe") buttons as described here http://developers.facebook.com/blog/post/559/
I have read that there are a fair few FB developers involved with this site, and was hoping that someone could shed some light on what I might be doing wrong / how to request FB changes the code to respect my request, or 406 me.
You are going to want to verify yourself as a developer in order to create a bug.
Check out this link for verification via -
mobile number
credit card
Once you have verified your account, head back to the bug system.

Get content-length from a URL which redirects to itself

I want to get content-length from a URL that it sends me this header:
HTTP/1.1 301 Moved Permanently Date: Sun, 01 Jan 2012 09:34:44 GMT Server: Apache Location: https://www.sugarsync.com, www.sugarsync.com/pf/D6304231_0192919_76577 Keep-Alive: timeout=300, max=9793 Connection: Keep-Alive Content-Type: text/plain; charset=UTF-8
The problem is that the original URL is the same new URL that in this header is sent! In other words: I get the headers from URL: https://www.sugarsync.com/pf/D6304231_0192919_76577 and in headers that I get, it redirects to the same page.
I don't seem to have that problem with the URL you provided:
C:\Users\rleahy>openssl s_client -quiet -connect sugarsync.com:443
Loading 'screen' into random state - done
depth=1 /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates
.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=
07969287
verify error:num=20:unable to get local issuer certificate
verify return:0
HEAD /pf/D6304231_0192919_76577 HTTP/1.1
host:www.sugarsync.com
HTTP/1.1 200 OK
Date: Sun, 01 Jan 2012 10:16:13 GMT
Server: Apache
Set-Cookie: JSESSIONID=22C35505626E63560F5F00BDE86BD458; Path=/; Secure
Content-Disposition: attachment;filename="Algorithms(01).rar"
Accept-Ranges: bytes
Etag: file_1319015834000
Last-Modified: Wed, 19 Oct 2011 09:17:14 GMT
Content-Length: 468987
Content-Type: application/x-download
Set-Cookie: NSC_wt_xxx.tvhbstzod.dpn_443=ffffffff090d78d545525d5f4f58455e445a4a4
2378b;path=/;secure;httponly
Are you sure you're not connecting with HTTP rather than HTTPS? Connecting with HTTP does indeed give a 301 (asking you -- in effect -- to connect using HTTPS).