Is the CURLOPT_CAINFO in the curl_setopt_array for PayPal in order for 'live' mode to work?
So basically what im asking is do we have to have SSL in order for PayPal live mode to work, because my script i have made works in sandbox, updates my db how i want it, but only in sandbox, not live. Im not wanting to post my script here I'll open a new thread for that, im just asking a general question so hopefully it will help me, or others in the feature, i searched Google and couldn't get a solid answer.
Have a great day!
As of using curl to make connection to Paypal, if Paypal does allow plain http connection, sure you don't worry about SSL. In that case, answer to your REQUIRED question is NO. But as you see, it depends on the service you are talking to. Let's say Paypal only allows https for production server, then you have to deal with SSL, either by ignoring it or set correct cert path. Both have to be done in set_opt. And here is another qa for this:
Source of PEM files for web service access
Related
I am using the magemonkey extension from Ebizmart and when i save my config in the admin i get the following error:
Could not add Webhook "http://example.com/monkey/webhook/index/wkey//" for list "Test Mailing List", error code 508, We couldn't connect to the specified the URL. Please double check and try again.
I did some digging and arrived at the conclusion (duh) that mailchimp cannot see my local environment so it's unable to add the webhook. Is it possible for me to configure this locally for testing purposes or do I have to wait until the site is live (sounds pretty strange to me)?
UPDATE: I reached out to Mailchimp and got the following response. Seems like they won't add a host entry to recognize my test environment. The only way to accomplish this would be to use a handshake key.
Thanks for reaching out to MailChimp support. I can certainly understand the concern here and will be happy to help.
Unfortunately, any webhooks being used must be publically available and there would not be a way to add a host entry in MailChimp so that the URL can be used.
If your testing environement allows for HandShake keys, one options might be to add that on to the url: (can't add more than 2 links)
At MailChimp we definitely appreciate testing and encourage it with our users and I will be sure to pass this feedback along to our developers so that testing in closed environments might be a bit easier. I also wanted to provide a link to our feedback form in case you wanted to leave some feedback for our developers directly: (can't add more than 2 links)
If you have any additional questions or concerns, feel free to reach back out and we will be happy to help.
Thank you,
Mikey
Use https://ngrok.com/, available for all platforms.
It allows you to tunnel requests to your local dev machine. It's very easy to use, just download and run:
ngrok http 80
Then it'll show you the forwarding URL (where xxx is randomly generated):
Forwarding https://xxxxxxxx.ngrok.io -> localhost:80
Use https://xxxxxxxx.ngrok.io as the begining of your webhook callback URL.
Once it's running, a web interface is available at http://127.0.0.1:4040 that shows metrics and let's you replay requests.
Is this possible with JavaScript or PHP? I want to be able to detect if my private CA is installed on the user's iOS or Android device. From there I can decide whether to provide instructions for installation or not. I've been "googlin" and haven't found anything useful. Has anyone tried this before? I want to find out what I should spend my time learning. If it's not possible, could you suggest an in browser alternative?
EDIT : I don't have a choice here and it's not my decision. A private CA certificate is going to be used for other security reasons.
I doubt there will be any sort of device query to test this.
I haven't actually done this, but you could probably come up with a test where the JavaScript makes an AJAX request to an https server that uses the certificate you want to test for. If the request succeeds, then the certificate is working. (This question seems to imply that AJAX requests will (correctly) fail if the SSL certificate doens't validate)
Note that, because the scheme (http or https) of the URL will be different (and maybe the domain depending on how you set this up), your test site will have to use the CORS Access-Control-Allow-Origin header to allow the browser to make the request. See: AJAX calls to untrusted (self-signed) HTTPS fail silently
EDIT:
I had some time and put together a very simple example. Goto http://ssl_test.gjp.cc . That page will attempt to make an AJAX request to https://ssl_test2.gjp.cc, which uses a self-signed certificate. Before you trusted ssl_test2, you will see "Failed" on the ssl_test page, however once you trust the certificate for ssl_test2, you should always see "Success" on ssl_test.
Note that this doesn't prove that your user has the CA cert installed - all it proves is that they have configured their browser to trust the test site (ssl_test2). If you never directly point the user to the test site, then they will never have the chance to trust only that site, so this should work reasonably well.
Maybe this will help :
<img src="https://the_site/the_image" onerror="redirectToCertPage()" />
I am new to the whole button encryption with paypal. It seemed like all I had to do is what is explained on this page http://www.stellarwebsolutions.com/en/articles/paypal_button_encryption_php.php
but it seems more like than just a plug in play. Seems as though I need Open SSL. I use hosting and don't know if I have the right to install Open SSL on my server or should I just get SSL in the first place since I will be using it in the next couple of months. Currently I have a apache server with cpanel. Any advice would be great. Thank you in advance.
This can be a bear to install and get working with your PHP code. The workaround is to not encrypt, but use a hash to detect tampering, and then reconfirm the hash when the IPN is processed. I explain this here:
How do I make a PayPal encrypted buy now button with custom fields?
i'm developing an application with multiple login and information export options like yahoo, google contacts, live contacts etc. I tried to do the oauth wrapper for aol, followed the examples in the http://dev.aol.com/api/openauth page but it doesnt works.
I just only wanted to know if there is anyone that chad succeeded with its specs and got some sample code working, i tried and got the token in response but when i try to do an api request i get the response : Key Used From unauthenticated site
does it have to run in a online server? do i have to get some rsa signed file on my server?
any hint is welcome, thank you very much!
I haven't tried it before but I think you have to tell them your the IP you will sent requests from..
I was making project over enom API and I had to send them my IP to authorize my API requests
sorry for my late response, have being little busy here. The code in the example finally worked right last time i tried, maybe their servers had some issues or i misconfigured the example, not sure, but in my project it didnt worked, finally i managed the solution by using the CURLOPT_REFERER parameter i found in the example. I am sure that it was the issue in my code, because i was testing in a devel environment with a .loc top level domain.
Finally i want to give a hint to all the people trying to develop 3rd party apps that check the validity of the urls asking for permissions, you could use a testing environment by using the CURLOPT_REFERER paramater by setting the production url you want in the testing environment.
file in the testing environment http://www.mycoolsite.loc.
curl_setopt( CURLOPT_REFERER 'http://www.mycoolsite.com' );
The site that will receive the answer will check the referer and assume the .com one instead the .loc
Thanks to everybody that tried to help me.
I've been experimenting with OpenID, and have set up a sample web page to access using my OpenID account. I'm using the Php OpenID Library by Janrain and it wasn't working with my Google Account. A little research led me to this question, which suggests the problem is that Google uses https and...
... it's likely the setup for making HTTPS requests is borked on your PHP server. Check to make sure you have the ca-certificates package installed.
In the same thread, someone links to their hacked version of the library which I deployed and have used with my Google Account successfully. Other questions have other customizations to get around similar problems (Janrain’s PHP-OpenID and Google/Yahoo, php-openID doesn’t work with Yahoo!, Example usage of AX in PHP OpenID...)
I'm not too hot on security, so I ask; does anyone know of a reason to not use these hacked versions?
Does the original library have whatever shortcoming these hacks fix by design, and therefore the hack is a potential security vulnerability?
Is there a qualified crypto-ifier out there who has looked at any of these solutions and gone "By David Chaum's beard! NO!!"
If so - and I therefore shouldn't use any of these hacks - how would I check that I "have the ca-certificates package installed"?
Here's what the author of one of those "hacked" versions wrote:
In particular CURLOPT_SSL_VERIFYPEER
and CURLOPT_SSL_VERIFYHOST are true by
default: I set them to false and it
worked for the test page!
The effect that has is to pretty much negate any security advantage offered by using HTTPS. The primary reason HTTPS is useful in OpenID is that it guards against a man-in-the-middle attack, i.e. some bad guy poisons your DNS cache to send all google.com requests to bad-guys.example. With properly configured HTTPS, you'd verify the certificate on the connection, find out it wasn't from Google, and say "I'm not going to believe anything you say, bad-guys!"
Unless, of course, you don't verify any certificates (you set all the SSL_VERIFY options to false), in which case your server will believe everything bad-guys says as if it were the real Google provider. You can imagine how that might be bad.
Now, frankly, this isn't the worst choice you could make, because it's no worse than just using HTTP, which a lot of people do anyway. You're just lying to your users if you imply that you're providing HTTPS-level security when you're not.
And there's a lot of information out there about how easy it is or isn't to do a dns-based attack, or how easy it is to forge SSL certificates. Either way, it does require someone to attack the connection between your server and Google, which is generally harder than attacking the connection between the user's laptop in the coffee shop and your server.
But still, much better to actually fix your PHP or CURL SSL configuration. Or if you don't, warn your users of that when they sign up with HTTPS identifiers, so they can choose if they really want to use that OpenID with your site.
Which leads to your second question. I think, not knowing anything about which server platform you're using, the best thing I can do is to link you to the Curl docs on SSL certificates; see the section that says "Get a better/different/newer CA cert bundle!"
From the Wikipedia article on Certificate Authority:
A CA issues digital certificates that contain a public key and the identity of the owner. When an end-user tries to access an unknown URL, the web browser (e.g. Mozilla Firefox and Microsoft Internet Explorer) will contact the CA to confirm the public key of the URL.
... so the CA Certificate is a Public Key Certificate used to communicate over https://. Your server should have CA Certificates on the file system somewhere. If not, you'll have to download the CA Certificate yourself and set the CURLOPT_CAINFO constant to point to its location. See this article.
http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/
[...] does anyone know of a reason to not
use these hacked versions?
Besides the fact that they're hacked versions, which are most likely undocumented and have no guarantee as to their behavior?
I can't answer specifically, but it there should be some warning lights flashing when you work with modules that have had quick fixes and workarounds applied, especially when you're dealing with authorization and security.. I think the best advice would be "Use at own risk!"
I'm sure someone with more knowledge on the topic will arrive soon enough with a more informed answer.