We've recently moved our web application to a new server and curl requests through PHP have stopped working for HTTPS addresses (HTTP still works fine).
The old server was running openSUSE 12.3 and the new server is Ubuntu 16.04.
I've tried curl_setopt( $ch, CURLOPT_SSLVERSION, 1 ); to force TLS as suggested in answers to similar questions here, but it makes no difference.
It's all the more confusing because an HTTPS request to the same location using curl at the command line works exactly as I'd expect.
I turned on verbose output in the PHP curl call to see if that would help me and got the following output:
* Trying xxx.xxx.xxx.xxx...
* Connected to www.somesite.com (xxx.xxx.xxx.xxx) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* Unknown SSL protocol error in connection to www.somesite.com:443
* Closing connection 0
but when I run the command at the command line (using something like curl -d "My=post&data=here" -X POST https://www.somesite.com/... -v) I get:
* Trying xxx.xxx.xxx.xxx...
* Connected to www.somesite.com (xxx.xxx.xxx.xxx) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 696 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.0 / RSA_3DES_EDE_CBC_SHA1
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: *.somesite.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=****,ST=****,L=****,O=****,OU=****,CN=*.somesite.com
* start date: Fri, 27 Jan 2017 00:00:00 GMT
* expire date: Wed, 26 Feb 2020 23:59:59 GMT
* issuer: C=US,O=thawte\, Inc.,CN=thawte SSL CA - G2
* compression: NULL
* ALPN, server did not agree to a protocol
...Response here...
Does anyone have any suggestions as to how to fix this, or what I can do to narrow down the cause of the issue?
UPDATE:
Here is the PHP code I'm using to try and find the cause of the problem:
$postvars="My=post&data=here";
$curl=curl_init(
"https://www.somesite.com/..."
);
curl_setopt($curl, CURLOPT_VERBOSE, true);
curl_setopt($curl, CURLOPT_STDERR, fopen('/tmp/sslerror', 'w'));
curl_setopt($curl, CURLOPT_POST, 1);
curl_setopt($curl, CURLOPT_POSTFIELDS, $postvars);
curl_setopt($curl, CURLOPT_HTTPHEADER, array('Content-Type: application/x-www-form-urlencoded'));
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl, CURLOPT_TIMEOUT, 30);
$result=curl_exec($curl);
echo curl_error($curl);
curl_close($curl);
echo var_export($result, true);
Related
(I edited the title, see EDIT below: GET path in the response contains spaces, requested path does not.)
I am working for a company that uses a "template system" to enable their markets (different countries) to host small web apps and making them "feel" like part of the main market website by pulling header, navigation, footer of the main website via curl:
So a php script uses curl to pull a special empty CMS page that contains only the relevant elements and placeholders for the web app to replace. This way, the web apps always have the current legal footer, header and navigation links to the main sections on the CMS and feel like being part of the cms albeit being hosted on their own somewhere else.
In this case, depending on an i18n parameter in the url, the script is curling a different template for each of ~50 markets.
Now the curious case: This is working for all templates but one, which is returning error 400 when being curled via https.
But when curled via http, 301 is returned, then another request to the previously faulty https URL is made, only this time it returns 200.
Does not work:
* Trying [server_ip]...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x562a5065a130)
* Connected to www.[company_name].pt ([server_ip]) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.[company_name].pt
* start date: Aug 23 19:02:44 2022 GMT
* expire date: Nov 21 19:02:43 2022 GMT
* subjectAltName: host "www.[company_name].pt" matched cert's "*.[company_name].pt"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x562a5065a130)
> GET [path] HTTP/2
Host: www.[company_name].pt
User-Agent:Mozilla/5.0 (compatible; Integrator https://[app_name].[company_name].com)
Accept:text/html
Accept-Encoding:gzip,deflate
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:115
Connection:keep-alive
Cache-Control:max-age=0
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* The requested URL returned error: 400
* stopped the pause stream!
* Connection #0 to host www.[company_name].pt left intact
Does work:
* Trying [server_ip]...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x562a5066c0f0)
* Connected to www.[company_name].pt ([server_ip]) port 80 (#0)
> GET [path] HTTP/1.1
Host: www.[company_name].pt
User-Agent:Mozilla/5.0 (compatible; Integrator https://[app_name].[company_name].com)
Accept:text/html
Accept-Encoding:gzip,deflate
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:115
Connection:keep-alive
Cache-Control:max-age=0
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html
< Content-Length: 185
< Connection: keep-alive
< Location: https://www.[company_name].pt/[path]
<
* Ignoring the response-body
* Connection #0 to host www.[company_name].pt left intact
* Issue another request to this URL: 'https://www.[company_name].pt/[path]'
* Trying [server_ip]...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x562a5066c0f0)
* Connected to www.[company_name].pt ([server_ip]) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.[company_name].pt
* start date: Aug 23 19:02:44 2022 GMT
* expire date: Nov 21 19:02:43 2022 GMT
* subjectAltName: host "www.[company_name].pt" matched cert's "*.[company_name].pt"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x562a5066c0f0)
> GET [path]
Host: www.[company_name].pt
User-Agent:Mozilla/5.0 (compatible; Integrator https://[app_name].[company_name].com)
Accept:text/html
Accept-Encoding:gzip,deflate
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:115
Connection:keep-alive
Cache-Control:max-age=0
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< content-type: text/html; charset=utf-8
< content-length: 15305
< date: Thu, 22 Sep 2022 09:25:35 GMT
< server: Apache
< x-robots-tag: noindex
< strict-transport-security: max-age=31536000
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< referrer-policy: strict-origin-when-cross-origin
< cache-control: public, max-age=3600
< expires: Thu, 22 Sep 2022 10:25:35 GMT
< pragma: public
< accept-ranges: bytes
< content-encoding: gzip
<
* Connection #1 to host www.[company_name].pt left intact
Calling the template in the browser works, with http and https.
curl from CLI works also for both http and https and returns 200, the error only occurs with PHP.
The script (a bit blown up for error search):
function curl($url){
$headers[] = "User-Agent:Mozilla/5.0 (compatible; Integrator https://[app_name].[company_name].com)";
$headers[] = "Accept:text/html";
$headers[] = "Accept-Encoding:gzip,deflate";
$headers[] = "Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7";
$headers[] = "Keep-Alive:115";
$headers[] = "Connection:keep-alive";
$headers[] = "Cache-Control:max-age=0";
/**/debug_to_console("init curl");
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
curl_setopt($curl, CURLOPT_ENCODING, "gzip");
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($curl, CURLOPT_SSLVERSION, 6);
curl_setopt($curl, CURLOPT_FAILONERROR, 1);
curl_setopt($curl, CURLOPT_VERBOSE, 1);
curl_setopt($curl, CURLOPT_STDERR, $verbose = fopen('php://temp', 'rw+'));
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
$data = curl_exec($curl);
if(curl_errno($curl)){
debug_to_console("curl url: " . $url);
debug_to_console("curl error: " . curl_error($curl));
//echo 'Request Error:' . curl_error($curl);
}
echo "Verbose information:\n<pre>", !rewind($verbose), htmlspecialchars(stream_get_contents($verbose)), "</pre>\n";
curl_close($curl);
return $data;
}
As mentioned, on other templates from other markets (on the same server) this is working fine. And I was told, that the instances are duplicated, so they all should have the same settings. Again, they are all on the same server. Unfortunately, I can't get them to check further until I'm pointing them into the right direction what to look at.
Tests with ssllabs.com showed no differences between the instances.
Being a Front End Dev, I'm really not getting any further at this point, after trying multiple suggestions for similar errors. I'm suspecting a wrong setting on that instance, but what instructions/hints can I give the server team?
Sorry I had to remove IPs and company/app names.
Thank you.
Edit: Not sure if this is relevant, for some reason, the line > GET /[path] HTTP/2 is different in the faulty curl attempt:
Every successful curl has one space between the path and HTTP/2, the faulty one has three spaces between the path and HTTP/2.
When using http instead of https, the line also has three spaces > GET /[path] HTTP/1.1), gets the 301 response and after redirect, the new attempt has only one space > GET /[path] HTTP/2.
The URL is not the problem, it is absolutely identical to other instances where there is no problem. Does the server add a space character itself on the initial curl attempt? What could cause added spaces? This has to be server side, the other instances don't mangle the initial GET path.
I am trying to connect to a server using ssl cert verification. on my local machine i run curl in verbose and i get:
* Trying X.X.X.X...
* TCP_NODELAY set
* Connected to server.com (X.X.X.X) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: ./XXX.pem
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
......<<connects correctly and does it's thing>>......
on my other linux box i do the exact same script and get:
* About to connect() to server.com port 443 (#0)
* Trying X.X.X.X...
* Connected to server.com (X.X.X.X) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* Closing connection 0
<< Curl error: 77 >>
I am using the exact same certs on both machines. I have tried a billion different things and cant figure it out.
What do i need to do on the failing machine to get it to connect correctly? What other info do you need to assist me. I am quite far out of my comfort zone on this one...I dont know if its a local cert on the machine thats causing the error....
here is the script I am using:
$path = "./someFile.pem";
$keyFile = "./someFile.key";
$ch = curl_init();
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSLCERT, $path);
curl_setopt($ch, CURLOPT_SSLKEY, $keyFile);
curl_setopt($ch, CURLOPT_SSLCERTPASSWD , $pass);
curl_setopt($ch, CURLOPT_CAPATH, $path);
curl_setopt($ch, CURLOPT_TIMEOUT, 300);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $xml);
curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
curl_setopt($ch, CURLOPT_VERBOSE, true);
curl_setopt($ch, CURLOPT_CERTINFO, true);
$response = curl_exec($ch);
EDIT***
I was given a pfx file and i did the following:
to export the private key: openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes
to export the certificate: openssl pkcs12 -in certname.pfx -nokeys -out cert.pem
to remove the passphrase from the private key: openssl rsa -in key.pem -out server.key
I then put each of those files in the dir that httpd.conf expects. access to the server works fine now over https://.
I did yum install ca-certifcates and got:
Package ca-certificates-2019.2.32-76.el7_7.noarch already installed and latest version
I dont know what else to do next. getting same error as above.
Hello i want use the FineTS HBCI Api of the Sparkasse Bautzen, they send me a list of Ciphers who are not supported anymore.
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
I try now to setup my php7.3 curl to using tls1.3 but fail on this, im using openssl 1.1.1d
Im using https://github.com/nemiah/phpFinTS
$this->curlHandle = curl_init();
curl_setopt($this->curlHandle, CURLOPT_SSL_CIPHER_LIST, 'TLSv1');
curl_setopt($this->curlHandle, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($this->curlHandle, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($this->curlHandle, CURLOPT_USERAGENT, "FHP-lib");
curl_setopt($this->curlHandle, CURLOPT_HEADER, 1);
curl_setopt($this->curlHandle, CURLOPT_RETURNTRANSFER, true);
curl_setopt($this->curlHandle, CURLOPT_URL, $this->host);
curl_setopt($this->curlHandle, CURLOPT_CONNECTTIMEOUT, $this->timeoutConnect);
curl_setopt($this->curlHandle, CURLOPT_CUSTOMREQUEST, 'POST');
curl_setopt($this->curlHandle, CURLOPT_ENCODING, '');
curl_setopt($this->curlHandle, CURLOPT_VERBOSE, '1');
curl_setopt($this->curlHandle, CURLOPT_TLS13_CIPHERS, 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256');
curl_setopt($this->curlHandle, CURLOPT_TIMEOUT, $this->timeResponse);
curl_setopt($this->curlHandle, CURLOPT_HTTPHEADER, array("cache-control: no-cache", 'Content-Type: text/plain'));
my verbose output:
* Connected to banking-sn5.s-fints-pt-sn.de (62.181.154.164) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: TLSv1
* TLS 1.3 cipher selection: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-SHA
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=DE; ST=Hessen; L=Frankfurt; O=Finanz Informatik GmbH & Co. KG; OU=Finanz Informatik GmbH & Co. KG; CN=banking-sn5.s-fints-pt-sn.de
* start date: Jan 29 00:00:00 2018 GMT
* expire date: Apr 29 12:00:00 2020 GMT
* subjectAltName: host "banking-sn5.s-fints-pt-sn.de" matched cert's "banking-sn5.s-fints-pt-sn.de"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
* SSL certificate verify ok.
> POST / HTTP/1.1
Host: banking-sn5.s-fints-pt-sn.de
User-Agent: FHP-lib
Accept: */*
Accept-Encoding: deflate, gzip
cache-control: no-cache
Content-Type: text/plain
Content-Length: 540
* upload completely sent off: 540 out of 540 bytes
* HTTP 1.0, assume close after body
< HTTP/1.0 403 Forbidden
< Server: BigIP
< Connection: close
< Content-Length: 28
<
* Closing connection 0
HTTP/1.0 403 Forbidden
Server: BigIP
Connection: close
Content-Length: 28
First of all:
They sent you a list of ciphers they don't support anymore, not a list of protocols. So you can still use TLSv1.2 as protocol. Basically they threw away the RSA ciphers.
To fix your probem:
Use:
curl_setopt($this->curlHandle, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
// CURL_SSLVERSION_TLSv1_2 means minimum TLS v1.2 but also 1.3 is allowed
// CURL_SSLVERSION_TLSv1_3 would mean minimum TLS v1.3
I also suggest to remove:
curl_setopt($this->curlHandle, CURLOPT_TLS13_CIPHERS, 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256');
// !!! here you force the Ciphers they forbid, so nothing is left to connect !!!
curl_setopt($this->curlHandle, CURLOPT_SSL_CIPHER_LIST, 'TLSv1');
// let openssl decide
Don't set a list of allowed ciphers at all, I would say.
Why: because if you have a trustworthy OpenSSL Vendor for your OpenSSL 1.1.1d the defaults should be useful. Its dangerous to force specific ciphers here, let the guys from OpenSSL decide here. So if you update Your PHP/OpenSSL you get things fixed without the need to change code, especially if you don't understand the details of TLS.
i have the following php code that calls an API:
$forcetest = 1;
$url = "https://www.website.com/api/pointTotal.php?userId=" . $userId;
if ($forcetest || (isset($_SERVER['ON_TEST_SERVER']) && ($_SERVER['ON_TEST_SERVER']))){
$url = "https://wwwtest.website.com/api/pointTotal.php?userId=" . $userId;
}
$curl = curl_init();
curl_setopt_array($curl, array(
CURLOPT_RETURNTRANSFER => 1,
CURLOPT_URL => $url
));
curl_setopt($curl, CURLOPT_HTTPHEADER, array(
'sharedSecret: abc123',
));
//curl_setopt($curl, CURLOPT_FOLLOWLOCATION, true); //tested to see if this would work, didn't seem to matter
// Only do this if on dev/test
if ($forcetest || (isset($_SERVER['ON_TEST_SERVER']) && ($_SERVER['ON_TEST_SERVER']))) {
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
}
$response = curl_exec($curl);
print($response);
if(!$response){
die('Error: "' . curl_error($curl) . '" - Code: ' . curl_errno($curl));
}
my problem is when going to production (i.e. $forcetest = 0;) it works just fine, calling the prod api and using the prod database. if i switch it, and it goes to the wwwtest subdomain to call the test api, i get the error returned
{"success":false,"errors":["Invalid API request"]}
"invalid api request" isn't something in the api's code, so it seems to me that its something curl_exec is doing/erroring on but i can't figure out what. if i go to the api's directly, they both return the correct information in my browser, so i know it's up and working. is it maybe a cert issue or some sort of xss setting on that subdomain/server that's causing it to error? i'm kind of at a loss.
Thanks in advance.
edit: CLI curl command and header output:
[josh#mac] $ curl -H 'sharedSecret: abc123' 'https://wwwtest.website.com/api/pointTotal.php?userId=1472&rewardsType=f' -vvv
* About to connect() to wwwtest.website.com port 443
* Trying xxx.xx.xx.xx... connected
* Connected to wwwtest.website.com (xxx.xx.xx.xx) port 443
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using RC4-SHA
* Server certificate:
* subject: /C=US/ST=New Mexico/L=Albuquerque/O=removed/CN=*.website.com
* start date: 2013-07-29 00:00:00 GMT
* expire date: 2016-10-05 12:00:00 GMT
* subjectAltName: wwwtest.website.com matched
* issuer: /C=US/O=DigiCert Inc/CN=DigiCert Secure Server CA
* SSL certificate verify ok.
> GET /api/pointTotal.php?userId=1472&rewardsType=f HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: wwwtest.website.com
> Accept: */*
> sharedSecret: abc123
>
< HTTP/1.1 200 OK
< Date: Wed, 29 Jun 2016 18:27:25 GMT
< Server: Apache/2.2.3 (CentOS) DAV/2 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5
< Access-Control-Request-Headers: accept, auth-key
< Access-Control-Allow-Origin: https://customeraccess.website.com
< Access-Control-Allow-Headers: sharedSecret
< Content-Length: 36
< Content-Type: text/html
Connection #0 to host wwwtest.website.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"userId":"1472","pointTotal":50600}
also added this to the php code making the call
curl_getinfo($curl, CURLINFO_HEADER_OUT) and it prints out a 404 which is what seems to be the problem but going to the url it's curl'ing immediatley returns the correct result so i'm not sure what's causing the 404
Sorry, just now saw this question was still open. The problem turned out to be bad internal DNS. the code and the curl we're all correct, i had to rely on the sys admin's to resolve it.
=====
UPDATE
I am having a degree of success connecting to the server with fsockopen. However, I would like to use cUrl if possible.
=====
Original
I am trying to make a request to flask using curl in the form of a post. The goal is not to use jQuery but to achieve more separation and validation of information. Despite being able to make a request from my desktop, I cannot make a request from my web server. I have iptables running and have listed the rules below. Also, I have listed the PHP code. I am not receiving any output from flask at all.
Technology:
Go Daddy Hosting account where the request is made
Go Daddy vps for the flask server
Iptables:
ACCEPT all -- c-xxx.xxx.xxx anywhere
ACCEPT all -- ip-xxx.xxx.xxx anywhere
The ip listing is from the web server but the c listing is from my desktop.
Curl Request from PHP
$ch=curl_init();
curl_setopt($ch,CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_TIMEOUT, 400);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, True);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, True);
curl_setopt($ch, CURLOPT_PORT, 8888);
curl_setopt($ch, CURLOPT_POST, count($data));
curl_setopt($ch, CURLOPT_POSTFIELDS, array('url'=>'login','user'=>$user,'pass'=>$pass,'auth'=>$authstring,'ip'=>$ip));
$result = curl_exec($ch);
This request is not even registering with tcpdump -i eth0 port 8888 unlike the requests from my desktop. The ip addresses are correct.
The request is working in Aptana.
The specific error is:
* Rebuilt URL to: xxx.xx.xx.xx/
* Hostname was found in DNS cache
* Trying xxx.xx.xx.xx...
* connect to xxx.xx.xx.xx port xx failed: Connection refused
* Failed to connect to xxx.xx.xx.xx port xx: Connection refused
* Closing connection 8
This is after completely flushing my iptables. In Aptana with the same php version, I get:
Trying xxx.xx.xx.xx...
* Adding handle: conn: 0x278fa30
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x278fa30) send_pipe: 1, recv_pipe: 0
* Connected to XXX.XX.XX.XX (XXX.XX.XX.XX) port XXXX (#0)
> POST / HTTP/1.1
Host: xxx.xx.xx.xx:xx
Accept: */*
Content-Length: 29
Content-Type: application/x-www-form-urlencoded
* upload completely sent off: 29 out of 29 bytes
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 4
< Server: Werkzeug/0.10.4 Python/2.7.5
< Date: Wed, 24 Jun 2015 07:04:28 GMT
<
Unfortunately, a hosting representative from GoDaddy told me that only the following ports are open to me. 80, 21 ftp, 22 SFTP, 445 ssl, 3306 mysql. Basically, I cannot send anything. I had to switch hosting services. A VPS from Go Daddy works too.