I've been trying to figure out what's wrong and what is the problem with this following PHP code, which is trying to make a SOAP call. I can't get it to work when I host the PHP on free web hosting sites
include_once("nusoap/lib/nusoap.php");
// create the client and define the URL endpoint
$client = new nusoap_client('http://xxxyyy.zzz:1881/');
// set the character encoding, utf-8 is the standard.
$client->soap_defencoding = 'UTF-8';
$client->call('sendSMS', array( 'uName' => 'kd81fg',
'uPin' => '18416',
'MSISDN' => '09156300965',
'messageString' => 'THIS IS A SAMPLE MESSAGE',
'Display' => '1',
'udh' => '',
'mwi' => '',
'coding' => '0' ),
"http://ESCPlatform/xsd");
When I tried using this hosted on my localhost, it work, but when I try to upload it (I tried so many free web hosting sites) to a web hosting site, and try to run it, it will not work.
I don't know what's wrong but I'm pretty sure that the code is perfect. I'm guessing that the free web hosting sites that I tried do not allow SOAP / XML , or maybe cURL is disabled, or url_fopen is Off on their php.ini (config) or something . I don't really know what's wrong right now and I need to finish what I'm doing right away.
UPDATE: I tried to echo what's the error and here what it says
HTTP Error: Couldn't open socket
connection to server http://xxxyyy.zzz:1881/, Error (111) Connection refused.
I checked the phpinfo for curl and stuff.
I was thinking of that too that maybe the problem is on the free hosts that they dont allow connection on port 1881, but I tried to scan and check if 1881 is open on my localhost, and it says my 1881 is closed, and now I'm confused.
Probadly port 1881 is closed on the free hosts. Try to close it on your pc/router. If the same error appears than this should be the problem.
EDIT: Did you check the phpinfo() for curl and stuff?
EDIT 2: Don't you have to add the client's host to your profile at the service provider's site like when you want to use the Google maps API?
Very often free web hosts will block outgoing ports. If you can set up a reverse proxy with apache or nginx (I'm assuming you're hosting the SOAP server).
Related
I am trying to download an external file using guzzle. This is the code that I use:
$url = 'https://testurl.net/dl/test.mp4?mime=true';
$path = storage_path('app/remote-uploads/test.mp4');
$client = new Client();
$client->get($url, ['sink' => $path]);
The code works and downloads from localhost just fine but when I push it to production I receive this error:
Client error: `GET https://testurl.net/dl/test.mp4?mime=true` resulted in a `403 Forbidden` response:
{"status":403,"msg":"download ISP is different to request ISP. request: AS20115 download: AS30083"}
I am not quite sure how to go about this and would really appreciate any help!
Seems that you are using https://openload.co/api#download-getlink to get a download link and download it then.
In this this I can assume that you hosting provider uses different IP for each outgoing HTTP request, and these IPs are even from different ASs (you think about them as "namespaces", check AS20115 and AS30083). And this particular site (openload.co) treats the situation like a security problem and prevents downloading (the second request).
There is nothing you can do on the application level. You have to talk to you ISP about it's routing rules. Maybe ask about (buy) a static IP address.
You can try to play around HTTP 1.1 keep-alive connections to send all requests through the same connection, but it depends on a server, and openload.co might not support this feature.
P.S. Please, include more details in questions in the future. Others are not wizards to read context from your mind :)
if you using vpn. please disable it
I have a website which frequently makes SOAP calls to a particular API. The site was working fine for a few months of time, however the SOAP functionality suddenly stopped working without any known reason, the error was "Cannot connect to host".
The WSDL service has not moved or shut down.
After this I updated plesk from version 12 to version 17. SOAP client is still not working but now its a different error:
SOAP-ERROR: Parsing WSDL: Couldn't load from (URL) : failed to load external entity (URL)
This is my SOAP call:
$opts = array('http'=>array('user_agent' => 'PHPSoapClient'));
$context = stream_context_create($opts);
libxml_disable_entity_loader(false);
$client = new SoapClient($url,array('stream_context' => $context,'cache_wsdl' => WSDL_CACHE_NONE));
Any possible solutions?
EDIT:
New information came in, so the API server had DNS problems, how can I restore my connection to the API?
Your php server is clearly not reaching out the soap server. This might help:
Try checking directly from php server if the service are reachable:
wget {url} > page.txt
nano (or equivalent) page.txt
Try using other program to consume the server, I suggest Soap Ui
On the php server try ping the service url and see if the IP is resolved.
Check if any other soap service is reachable, you can use this service
If this not help you coming up with a solution, post here the results to help others solving it.
So I'm having a big issue and it protans to Socket.IO and the connection. The 'host' IP along with the port number I've entered does not want to connect. I've tried adding LocalHost, the plain IP Address, along with a variety of port numbers.
PHP Code:
var HOST = "/";
I solved the issue by doing this, but in the Chrome console, I get this error:
socket.io-1.4.5.js:1 POST http://192.168.1.222/socket.io/?EIO=3&transport=polling&t=LIjrKSc 404 (Not Found)
I have socket.io located like: template/js/new.js
I'm not entirely sure why this issue is occuring, I'm still going to do a little research, but if anyone has a solution to this, please inform me of so.
Thanks! ~mrgreen33gamer
I am currently trying to connect to my elastic search cluster using the php elasticsearch client
I am having trouble using an https endpoint for this. I have my cluster behind a load balancer with a VIP in front, it is using Apache authentication and is on port 443. The trouble I am running into is that the config for the client seems to be parsing the hosts and removes https:// from the host name. this results in the client always trying to connect over port 80. I have tried adding :443 to the host name but I am then getting a curl error "empty reply from server". I know that this server has access (no firewall blocking) because i can manually make the curl call using https://myelasticsearch.com.
My question is, is there a way to specify the protocol to make the request over using this client? if not, where in the source is the parsing of the host array happening?
I have found a temporary solution, in src/Elasticsearch/Connections/AbstractConnection.php there is a defined transportSchema variable that is set to http. I changed this to https and also added the :443 to my host in the config and it works!
Just as an update to this question (in case anyone stumbles into it), this bug was fixed in Elasticsearch-PHP v1.1.0. You can specify https in the host now to use SSL:
$params = array();
$params['hosts'] = array (
'https://localhost', // SSL to localhost
'https://192.168.1.3:9200' // SSL to IP + Port
);
$client = new Elasticsearch\Client($params);
i've been trying to set up a secure communication using client side certificate between my client application and my server application.
I've set up a the configuration in my apache web server and both in my browser just to make sure that it works and it does.
i'm using zend framework 1.12, and according to the documentation on Zend website
the following example should work:
$config = array( 'sslcert' => 'path/to/ca.crt', 'sslpassphrase' => 'p4ssw0rd');
$adapter = new Zend_Http_Adapter_Socket();
$adapter->setConfig($config);
$http_client = new Zend_Http_Client();
$http_client->setAdapter($adapter);
$http_client->setUri('https://somewhere.overtherainbow.com:1337/bluebird');
$http_client->request();
but everytime i just get the same exception
Unable to Connect to ssl://somewhere.overtherainbow.com:1337
There is no doubt that i'm using the right certificate and passphrase and there is access to the remote machine
so where could be the downfall ?
Sounds like a simple firewall issue - login to the server and stop iptables and then see if it connects. Or add an exception to the clients IP to access mysql. Also check :1337 is open