Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 5 years ago.
Improve this question
I am using the PayPal Permissions SDK (Classic/NVP) to seek authorisation for third party payments.
The first time someone clicks on my button that redirects them to PayPal to login and authorise the request they get end up at the PayPal home page. If they go back and click my button again, it works this time and takes them to the right PayPal page.
Here is my code:
RequestPermissionsRequest rp = new RequestPermissionsRequest();
rp.scope = new List<string>();
rp.scope.Add("EXPRESS_CHECKOUT");
rp.callback = "my return url here";
rp.requestEnvelope = new RequestEnvelope("en_US");
RequestPermissionsResponse rpr = null;
PermissionsService service = new PermissionsService(PayPalClassicHelpers.Configuration.GetAcctAndConfig());
rpr = service.RequestPermissions(rp);
Response.Redirect("https://www.paypal.com/webscr&cmd=_grant-permission&request_token=" + rpr.token);
This redirects them to the PayPal URL:
https://www.paypal.com/webscr&cmd=_grant-permission&request_token=***rpr.token value***
But the first time they end up here:
https://www.paypal.com/us/home
Looking at the request and response headers, the first time I see this:
GET: https://www.paypal.com/webscr&cmd=_grant-permission&request_token=***
Response: HTTP/2.0 200 OK
Various CSS, JS and image requests
POST: https://www.paypal.com/auth/validatecaptcha
Response: HTTP/2.0 302 Found
Location: /webscr&cmd=_grant-permission&request_token=***
GET: https://www.paypal.com/webscr&cmd=_grant-permission&request_token=***
Response: HTTP/2.0 302 Found
Location: https://www.paypal.com/home
On subsequent requests there is no POST to https://www.paypal.com/auth/validatecaptcha.
I have tried this on a few networks and computers and it is always the same.
Has anyone experienced this and know of the cause and a solution?
Just use '?' symbol after the webscr.
For example, change
https://www.paypal.com/webscr&cmd=_grant-permission&request_token= to
https://www.paypal.com/webscr?cmd=_grant-permission&request_token=
I am not sure but I have experienced the same issue when testing and debugging my code for PayPal recurring billing.
This is, most of the times in my case is because user is already logged in with other account and PayPal saved some cookies in the browser.
This might be the saved cookies issue and various accounts often used during development, such as sandbox seller and sandbox buyer.
Do check that and see if issues persist.
Again These are just my experiences and if your real users are actually experiencing this in production app then it might be something else completely.
Related
How can I determine the source URL of a GET or POST request sent to a Google Apps Script web application?
I am making a (PayPal IPN) listener script and would like to be able to distinguish weather the request came from a the test environment (sandbox) or from the live environment.
The origin of the request to the listener determines the response from the script. The listener has to send a response back to PayPal and depending on which environment the request came from, the response needs to go back either to the sandbox server or to the live server.
I am hoping to distinguish between requests from sandbox.paypal.com or www.paypal.com, in my Google Apps Script.
To work around this requirement, I have set it manually for now:
if (PPRunMode == 'test') {//in testmode send response to sandbox site
PPUrlBase = "https://www.sandbox.paypal.com/cgi-bin/webscr";
}
else {//url for live website
PPUrlBase = "https://www.paypal.com/cgi-bin/webscr";
}
But was wondering if this can be determined automatically.
Unfortunately, no request-source information is provided to your Google Apps Script web application, so there is no direct way to determine where a request came from.
You do have the ability to provide parameters to your web app, though, so you could have the code in the sandboxed environment use that to indicate a test condition.
For example, this URL could be used by the sandboxed code for a GET request:
https://script.google.com/macros/s/---SCRIPT-ID---/exec?test=true
^^^^^^^^^^
In the doGet(e) function, you would handle the parameter like this:
function doGet(e) {
if (e.parameter.test) { //in testmode send response to sandbox site
PPUrlBase = "https://www.sandbox.paypal.com/cgi-bin/webscr";
}
else {//url for live website
PPUrlBase = "https://www.paypal.com/cgi-bin/webscr";
}
...
}
For a POST request, the solution is similar. See URL parameters in the Web Apps and Google Sites Gadgets guide for details.
If you publish your Google App Script you get two urls :
https://script.google.com/macros/s/AKfycbxsCNyssA0dzMMmsNip3DW66hiJ62ks_F1yYUn0SDu073S2dOw/exec
https://script.google.com/macros/s/AKfycbxzpvZ9e9_vzs3d6Q0ky_RHLoYDruCl-6Xm8D6YmI4/dev
You can notice the difference, not sure if that is what you are pointing to
I'm trying to get PayPal Here to issue a callback to a FileMaker Go database. It looks like the fmp:// protocol is being used correctly, but seems that there may be some kind of other problem with the callback URL.
Here's the URL that I'm using to call PayPal Here (note that I'm not stripping out the carriage returns from the base64-encoded invoice in my application; this is the actual URL my application sends to the OS, and the invoice appears to be fine in PPH):
paypalhere://takePayment?as=b64&accepted=card%2Cpaypal&returnUrl=fmp:%2F%2F$%2Ffmg_pphTest&step=choosePayment&invoice=eyJwYXltZW50VGVybXMiOiJEdWVPblJlY2VpcHQiLCJkaXNjb3VudFBlcmNlbnQiOjAsImN1cnJl
bmN5Q29kZSI6IlVTRCIsInBheWVyRW1haWwiOiJjcmlzdG9zK3Rlc3RAY3Jpc3Rvc2xjLmNvbSIs
Iml0ZW1MaXN0Ijp7DQogICAgIml0ZW0iOiBbDQogICAgICAgIHsibmFtZSI6IkRpbGl0aGl1bSBD
cnlzdGFsIiwiZGVzY3JpcHRpb24iOiJNYWtlcyBzaGlwIGdvIGZhc3QuIiwidW5pdFByaWNlIjow
LjEsInF1YW50aXR5IjoxMCwidGF4UmF0ZSI6MCwidGF4TmFtZSI6IlRheCJ9DQogICAgXQ0KfX0=
This is the URL that I want to fire (this is just for testing; later on, there will be additional parameters added on to send the payment status, etc., but I can't even get this basic version to work yet):
fmp://$/fmg_pphTest
However, the behavior I'm seeing looks like this is the URL PPH is actually sending:
fmp://
Testing is being done on an iPad 2 running iOS 8.3. Any thoughts/suggestions out there?
A kind soul on the FileMaker Community boards pointed me at a working example, https://github.com/Genecom/FileMakerSampleSolutions. After doing some comparisons, I discovered the issue is due to using base64-encoding of the JSON invoice object. When I changed it to use URL-encoding of the JSON invoice (like the Genecom example), I was able to get the callback URL to work successfully.
I opened an issue on the PayPal Here github project, please feel free to chime in there if you've also experienced this issue (or found countervailing evidence): https://github.com/paypal/here-sideloader-api-samples/issues/26
Sometimes, when I post a reply to a comment through the graph API on a FB page (replies are enabled in the page parameters), I get generic FB "transient" errors which are not transient:
{u'error': {u'code': 2, u'message': u'An unexpected error has occurred. Please retry your request later.', u'is_transient': True, u'type': u'OAuthException'}}
A typical example is: https://www.facebook.com/VoyagesSncf.com/posts/377070219021428 where I cannot even post replies myself using the FB web interface.
I wonder if someone would know what could cause this specific FB discussion to behave this way and what I could do to detect programmatically that I need to give up on posting a reply and s
It seems to be a facebook api's bug, reported here: https://developers.facebook.com/bugs/281179468741734/
I've got the same problem while creating a new (even unpublished) post. But it is transient indeed, but it may took a few ours, when facebook will behave as expected.
I'm afraid, there is no workaround for this issue for now.
this would be yet another question for the vague Facebook Error Message:
"Error Parsing URL Error parsing input URL, no data was scraped",
as other posts regarding this issue went unanswered:
#1. by Vincent Guyard
#2. by Daniel Tiru
#3. by Fernando Quirino
#4. by user1964054
and this list goes on..
our case is a bit different, we have recently purchased a new domain name and performed
a transition from our old domain to the new one.
before the transition we were able to promote and advertise our website on Facebook.
after the transition we cannot do so neither with our new domain name nor with our old domain, attempting to do so we get a general error message:
"You've selected an object that cannot be promoted. Please choose a different object".
as if we have been black-listed for reasons which are beyond our knowledge.
The transition by it self was straight forward by adding a new binding to our website
on our IIS server for incoming requests with our new domain name, that is, we have not
changed our contents, nor did we change in our website pages code or structure, or for this matter changed our IP or migrated to another server.
when we tried to debug our url with: https://developers.facebook.com/tools/debug
we got Facebook infamous vague error message: "Error Parsing URL Error parsing input URL, no data was scraped.".
considering that we have not made any changes to our website in terms of content, structure or code, we presume that perhaps our new domain name "has a history" with Facebook.
Turning to Facebook support we were directed here..
with much respect for stackoverflow (and there is very much!), it is a big shame that Facebook detaches its self from supporting users of its own platform.
Back to our problem, has anyone encountered the scenario listed above?
or has a vague idea :) what might be the problem? and perhaps how can it be solved?
or where we can approach with it for consulting?
As for now we did not yet receive a feedback from Facebook to our issue.
Cheers!
I'm troubleshooting an issue where the Like button won't work on my site unless the URL is submitted to the Facebook debug tool.
When I hit like I'm seeing two requests fire to comment_widget_shell.php. Once succeeds (302 found), while the other fails, showing a status "(canceled)" and type "pending":
The successful request:
Request URL:http://www.facebook.com/plugins/comment_widget_shell.php?locale=en_US&master_frame_name=f236db264&offsetX=0&sdk=joey
Request Method:GET
Status Code:302 Found
The failed request:
Request URL:https://www.facebook.com/plugins/comment_widget_shell.php?locale=en_US&master_frame_name=f236db264&offsetX=0&sdk=joey
As of the writing of this question, here is an example URL where like fails:
http://www.zujava.com/geisha-makeup
I iniitally thought it was this Stack Overflow issue, as the site runs on a platform somewhat similar to Heroku, but for Drupal (Pantheon) and I can't reproduce the issue locally. However, I contacted Pantheon support and they reported the Heroku limitation does not exist on Pantheon.
I'm not sure what other tools I can use to debug this. My article pages get a clean report from the Facebook Debugger. Any ideas or tips of what I can look deeper into?
I have had pretty good luck with pantheon. If your just trying to get a like button on drupal why not use http://drupal.org/project/fb_social/ I have used this in d7 and d6 and I have never had a problem.
Pantheon should be able to handle a request to facebook for sure
thanks
Nick