I am creating a php application with the Coinbase API and the blockchain.info API. My (000webhost.com) webhost's communications with coinbase.com and blockchain.info API servers are getting a HTTP 403 CloudFlare Captcha. This completely cripples the API. I tried connecting with HTTPS, and tried changing the user agent, tried curl(), tried file_get_contents(), but I can't seem to get a real response from the API servers.
This is the error I get:
http://s10.postimg.org/ff8ggm6yx/Cloud_Flare_error2.jpg
Thanks for any help, I've been trying to figure this out for days.
The captcha is a security challenge page presented based on the security settings selected by Coinbase. Either the IP you're using or the user agent you're sending triggered the security challenge page here. If you complete the captcha (in a browser) a cookie would be temporarily set indicating you've passed this security challenge page successfully. Your best bet would be to contact Coinbase's support folks if you are still seeing this issue, and request that they consider whitelisting your IP address so that in the future you wouldn't receive a security challenge page like the one you indicated.
Disclaimer: I work at CloudFlare.
Related
We used the third-party web app and tried to integrate this Google API for Translation.
Currently, it's working OK. We can call the API to do the translation.
However, when we started to restrict this by using the HTTP REFERRER. We keep getting: Requests from referer are blocked.
On the URL, we tried the combination below and no luck:
*.ourdomainname.com/*
ourdomainname.com/*
The developer helped us to identify this and come up with this error detail:
Requests from referer <empty> are blocked.
Any ideas? Currently, it's working OK if we are not putting any restrictions, which is not good :) We prefer to restrict this.
I'm appreciated your feedback.
Thanks
I have app that logs in every couple hours on different servers and does some request on behalf of a business Instagram account via private instagram api. It's working well, but sometimes it gives me checkout point error and I have to manually open Instagram insert a code received via email or SMS. Cann't use such a service in production since this scenario could occur any time! Some long time ago it was just fine... Is there a way to bypass this checkout?
I guess they does this lock due to IP changes. Any ideas are appreciated.
These are Instagram's security measures and only way to make sure these won't pop up is to use same useragent, device ids and IP. But you could use SMSPVA API which will help you automatically verify the accounts
I've inherited this project where the user's credit cards are saved via the Sagepay token card details iFrame. The token used is retrieved through the 3.0 protocol.
The form iFrame is loading fine as you can see here:
But when I try to submit a test card, it fails with Server error 5003: Internal server error.
I can't really debug this as everything is happening on the Sagepay side and the error is so broad.
Any ideas of why this could be happening?
Thank you!
I suspect this is a failure to reach your notificationURL (that usually manifests itself as a 5006 for a standard transaction, but is 5003 when registering a token).
Make sure your notificationURL is externally accessible, isn't using a port number (Sage Pay will only communicate over http/https default ports 80 / 443), and all your firewalls are open - I think test notification posts originate from IP 195.170.169.29 if that helps.
I'm doing a website with Realex as the payment gateway. I want to integrate remote realex payment method in my website.
I know when we go live we need SSL enabled on our website to do remote method payments. But my question is, Is SSL required when we are doing testing?
Every time I test, it results in error (remote method), but when I do Real Auth method there is no problem.
I don't know what the exact problem is. Am i missing something?
No. We use Realex, and don't use SSL on our test sites.
In fact, if we don't use SSL on our live sites, it still generates no error. Realex doesn't actually have any way to know whether or not you're using SSL.
As TRiG has already said, Realex have no way of telling whether or not you have SSL on your website. However, your customers will not feel safe entering card details if they don't see the little padlock, and this will affect your sales conversion.
Communications between your server and Realex are https/SSL, so this is secure, but the card data must first get from the browser to your server securely. You may prefer to use the Realex Redirect integration if you do not want to buy an SSL cert.
Owen
at merchant site in live / testing ssl is not required
it results in error . may be due to
your response URL is not set
or you are trying to get the response from local host
to set response URL have to contact Realex support ...
it is the same as we do in papal notify
what response URL we send that is to compare not to set
I'm using the Zend Framework, specifically the Zend_Feed class, to grab the Facebook XML feed at http://www.facebook.com/feeds/page.php?format=rss20&id=120635284755 and merge it with a similar Twitter feed for display on a website.
The problem is that while I can grab the feed absolutely fine from both my local and remote testing servers, when I launch the app live at [http://www.pycsam.com.au], it is receiving a 403 response code.
Until I work out what is going wrong, I am mirroring the Facebook feed through my testing server, which proves that it works just fine, but it's not a good long-term solution since it requires an extra request.
Is anybody able to tell me why I would be receiving a different response from the Facebook server when the request is coming from different servers?
Many thanks in advance!
403 means "Forbidden". This can have any number of reasons:
You need to authenticate at some point, and the authentication doesn't work
The IP you are making the request from is blocked by Facebook's servers for some reason
There is a proxy somewhere in between blocking access (rather unlikely I'd say)
you may be able to get more detailed info by checking what the request body has to say.