ugrás a tartalomhoz

SoapClient, __doRequest, Could not connect to host - segítség

tisch.david · Okt. 27. (P), 19.30
Kedves Kollégák!

Egészségügyi alapellátási rendszerfejlesztőként csatlakoznunk kell az új eEgészségügy felhőjéhez. Mi, fejlesztőként, csak a DEV környezethez kaptunk hozzáférést, ezen ki is fejlesztettük az adatkapcsolatot PHP 5 nyelven, WSDL-es SoapClient hívásokkal, teszt tanúsítvánnyal titkosítva a kommunikációt. A kód Debian + Apache környezetben fut.

Most át kell állnunk az éles környezetre, ami a szolgáltatást nyújtó állami szerv szerint pusztán egy szolgáltatási végpont (location) cserét jelent a SoapClient-nél, valamint egy új tanúsítvány használatát teszi szükségessé. A kért módosítást elvégeztük, mégsem működik a dolog. Ha azonban a kódot - kompletten, tanúsítványostul, WSDL-esektül - localhostból futtatjuk, akkor tudunk kapcsolódni a célszerverhez.

A célszerveren a __doRequest híváskor az alábbi Exception lép föl:
object(SoapFault)#2 (9) {
  ["message":protected]=>
  string(25) "Could not connect to host"
  ["code":protected]=>
  int(0)
  ["trace":"Exception":private]=>
  array(2) {
    [0]=>
    array(6) {
      ["function"]=>
      string(11) "__doRequest"
      ["class"]=>
      string(10) "SoapClient"
      ["args"]=>
      array(4) {
        [0]=>
        string(1188) "...xml..."
        [1]=>
        string(53) "https://if.eeszt.gov.hu:443/ESZIGEID/ESZIGEID_NO_SAML"
        [2]=>
        string(0) ""
        [3]=>
        int(1)
      }
    }
    ...
  }
  ["previous":"Exception":private]=>
  NULL
  ["faultstring"]=>
  string(25) "Could not connect to host"
  ["faultcode"]=>
  string(4) "HTTP"
}
Tudom, hogy nagyon általános ez a hibaüzenet, de nincs valami ötletetek, hogy merre indulhatnék tovább? Próbáltam már másik - mások által jónak tapasztalt - tanúsítvánnyal, átigazítottam már - próbaképpen - a végpontot a WSDL-ben is, telnettel próbáltam kapcsolódni a szerverhez (azt írta, hogy connected), próbáltam localhoston böngészőből kapcsolódni a célszerverhez, Firefoxba importált tanusítvánnyal (az is ment).

A SoapClient objektumom így van inicializálva:
	$soapLocation = (DEV_ENV ? 'https://dev-if.eeszt.gov.hu:443' : 'https://if.eeszt.gov.hu:443').$soapLocationUri;
	$soapClient = new SoapClient(
			'./wsdl/'.$wsdlFileName,
			array(
					'local_cert'					=> (DEV_ENV ? './cert/***.pem' : './cert/***.pem'),
					'passphrase'					=> (DEV_ENV ? 'xxx' : 'xxx'),
					'location'						=> $soapLocation,
					'trace'								=> true,
					'exceptions'					=> true,
					'keep_alive'					=> true,
					'connection_timeout'	=> 10,
					'cache_wsdl'					=> WSDL_CACHE_NONE,
					'soap_version'				=> SOAP_1_1,
					'stream_context'			=> stream_context_create(array(
							'ssl'	=> array(
									'verify_peer'				=> false,
									'verify_peer_name'	=> false,
									'allow_self_signed'	=> true
							)
					))
			)
	);
Segítségeteket előre is köszönöm!
Üdvözlettel:

Dávid
 
1

Azon a szerveren ahol a ti

firith · Okt. 27. (P), 23.51
Azon a szerveren ahol a ti kódotok fut, engedélyezve van a kifelé menő forgalom? Vannak olyan szolgáltatók ahol minden kimenő forgalom le van tilva es ha csatlakozni akarsz külső szerverre azt fel vetetni velül a tűzfalukon.
2

Kedves Firith! Köszi a

tisch.david · Okt. 28. (Szo), 23.25
Kedves Firith!

Köszi a választ! Ugyanez a kód a https://dev-if.eeszt.gov.hu:443 oldalhoz tud csatlakozni, csak a https://if.eeszt.gov.hu:443-hoz nem, ráadásul a szerver a mi virtuális szerverünk, és a másik kód futásához se kellett állítani rajta semmit. Szóval nem hiszem, hogy tűzfal probléma lenne. Ha esetleg a PFX-ből PEM-be átalakított tanúsítvánnyal lenne a probléma, akkor vajon viselkedhetne így, hogy loclahostból megy, az éles szerveren pedig nem?

Előre is köszi a választ!
Üdv:

Dávid
3

Kipróbáltad a tűzfalat, vagy

BlaZe · Okt. 29. (V), 01.06
Kipróbáltad a tűzfalat, vagy csak tippelsz? Kapcsolat felépül a másik oldallal? Ha igen, a másik oldalon mi van a logokban? Stackoverflows válaszokkal mire jutottál (sokan kérdezték ezt)? PHP verziók egyeznek (PHP 5.6-nál tapasztaltak ilyesmit)?
4

Szia BlaZe!Köszi a

tisch.david · Okt. 29. (V), 08.48
Szia BlaZe!

Köszi a választ!
1. Próbáltam kapcsolódni telnettel a https://if.eeszt.gov.hu:443-hoz, amire azt írja, hogy Connected... Megmondanád, hogy ezen kívül hogyan tudnám még ellenőrizni a tűzfalat? Szolgáltatónál üzemeltetett virtuális szerverünk van, írtam ezzel kapcsolatban a helpdeskjüknek is, hogy nézzék meg, de nem tudom, hogy mikorra válaszolnak. Az nem bizonyíték, ugye, hogy a https://dev-if.eeszt.gov.hu:443 kapcsolat megy?
2. Hogyan tudom megnézni, hogy a kapcsolat felépül-e? A localhost-os kéréseknél néztem Whiresharkkal a forgalmat: adatküldés előtt megy - ugye - az SSL kézfogás, tanúsítvány csere, stb. Mivel a __doRequest villámgyorsan visszatér és utána a __getLastRequest és a __getLastRequestHeader is NULL-t ad vissza, ezért az a gyanúm, hogy tanúsítvány probléma van. Erről mit gondolsz? Megkértem az ÁEEK-t is, hogy nézessék meg az üzemeltetéssel a logot, de nem értenek hozzá, és van, hogy hetekig(!) nem válaszolnak.
3. Nagyon sokat Google-oztam már, és sok mindent ki is próbáltam (SoapClient init paraméterek beállítása (azt be is állítottam), végpont csere a WSDL fájlban (nem oldotta meg a dolgot), stb.), de eddig egyik sem segített. Egyedül a tanúsítványt nem csesztettem eddig (pem fájl és crt fájl szétválasztása, stb.), mert nem értek hozzá ennyire, mert egy másik, jónak mondottal se megy és, mert loclahostból Windows-on, WAMP-pal ugyanezzel a pem tanúsítvánnyal megy a dolog. Tudnám esetleg valami alternatív eszközzel (cURL, stb.) kiszűrni, hogy nem azzal van-e gond?
4. A PHP verzióm a szerveren 5.3.3, localhoston pedig 5.5.12.

Hálásan köszi a rám szánt időt. Bármit javasolsz, megnézem, csak tudjak már kitörni ebből az egy helyben topogásból.

Üdv:

Dávid
9

Ok, szóval akkor arról a

BlaZe · Okt. 30. (H), 01.27
Ok, szóval akkor arról a szerverről tudsz telnetelni, ahonnan futtatnád. Akkor ez nem nagyon lesz gond (btw én is tudok oda telnetelni mobilnetről, szóval nem egy zárt rendszer).

Pár további gondolat:

1) A cert kicsit homályos nekem, hogy ott mit kellett változtatni, írtál pemről, pfxről. Volt 2 pem file, az egyik a deves certificate, a másik pedig a prodos? Rootca ugyanaz a két certificate esetében? Mivel ha jól értem, más változás nincs, csak a pem tartalma. El tudom képzelni, hogy más a rootca, és a prodos valamiért nem trusted. Bár elég furán hangzik, pláne hogy localból megy.

2) wget, curl is kéne tudjon pemmel dolgozni, érdemes megpróbálni.

3) Esetleg szervereteken PHP error logban van valami?

4) PHP verziót szinkronizálj. Elsőre localban érdemes lehet kipróbálni a szerver verziót (gondolom ez gyorsabb).

5) Ne fogadd el, ha nem válaszolnak emailre rövid időn belül. Subject utaljon a prod kockázatra, levél első soraiban a várható probléma legyen és deadline, csak ezután az, amit tapasztalsz. Cc te főnököd, cc másik oldal főnöke. Lehet én dolgozom túl megoldás orientált környezetben, de elképzelhetetlen, hogy egy prodos kockázatot hordozó levél válasz nélkül maradjon.

Sajnos magát a PHP-s SoapClientet nem ismerem, így annak paraméterezéséhez nem tudok hozzászólni.
10

Szia BlaZe! Hálás vagyok a

tisch.david · Okt. 30. (H), 19.48
Szia BlaZe!

Hálás vagyok a segítségedért!

0. Igen, nem a hozzáférés a gond. Azóta a szerver technikai adminja is írta, hogy nincsen http/https-re tűzfal beállítva.

1. Volt 2 PFX cert, egyik a DEV, másik a PROD környezethez. Mindkettőt importáltam Windows-on, aztán exportáltam őket tanúsítvány láncostul, minden tulajdonságostul, végül openssllel - minden extra paraméter nélkül - PEM-et csináltam belőlük. Sajnos azonban nem igazán értek a certekhez. Hogyan tudom megnézni, hogy mindkettőnek ugyanaz-e a rootca-ja? Hogyan tudom ellenőrizni, hogy trusted-e a prod? (Bár ezt én se tartom valószínűnek.)

2. Megpróbálom majd megnézni.

3. Apache logok (access, error) üresek.

4. Kértem PHP upgrade-et a szervergazditól. Remélem, kapok.

5. El nem tudod szerintem képzelni, ha csak nem dolgoztál még valamilyen állami szervnek, hogy ezek a fejlesztések hogyan zajlanak. Fejlesztési kulcskérdésekben is megengedik maguknak azt a luxust, hogy hetekig nem válaszolnak a feltett kérdésekre. Én most már kezdek arra a véleményre jutni, hogy jeleztem a problémát a hivatalos helpdesken keresztül, és kértem tőlük egy k***a szerver oldali logot. Delegálták a feladatot a felelősnek, ő meg sz@rik válaszolni. Amíg nem biztosítják a technikai feltételeket a csatlakozáshoz, addig nem tudunk csatlakozni. Pont. Lopják az időm, én lopom a tiéteket, és ők meg NEM HAJLANDÓK MEGNÉZNI egy log fájlt, hogy mi a gond. Érted?! A fontos fejlesztések meg úsznak el, mert megy az idő a pisipogácsázásra... Agyrém...

Légyszi, azért még a certesre válaszolj, ha tudsz! Nagy segítség lenne!
Hálás köszönettel:

Dávid
13

5.6-nál elég sok változás van

inf3rno · Okt. 31. (K), 06.15
5.6-nál elég sok változás van SSL-nél. link
5

Utánanéztél mit jelent a

inf3rno · Okt. 29. (V), 14.23
Utánanéztél mit jelent a hibaüzenet? https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language Ránézésre valami jogosultsági hiba lesz. Egyébként gondoltam, hogy a szuper új egészségügyi rendszer ezer éves elavult SOA-val lesz megvalósítva nem REST-el, ami legalább skálázódna is. PHP-vel ez kiváltképp fájdalmas lehet, annyira bugos egy retek a SOAP kliens.
7

Kedves inf3rno! Köszönöm a

tisch.david · Okt. 29. (V), 23.38
Kedves inf3rno!

Köszönöm a válaszodat! Mostani, szorult helyzetemben különösen is hálás vagyok érte!

Meg tudnád mondani, hogy miért éppen a SAML wiki cikket idézted, és mi alapján gondolod, hogy jogosultsági a probléma? A szóban forgó hívás ugyanis 5-6 - a felhasználóra vonatkozó - "konstans" paraméterrel meghívja az Elektronikus Egészségügyi Szolgáltatási Teret, ami visszaad egy, a BM-nél az EESZT-t azonosító, titkosított kérés csomagot, amit aztán localhoston az eSzemélyi kliens felé továbbítva lehetővé válik az eSzig-ből történő TAJ kiolvasás. Ha itt minden OK, akkor a végén visszakapunk egy tokent, és ezzel lehet aztán majd SAML ticketet kérni... Szóval ennek a hívásnak - szerintem - még nincs semmi köze a SAML-hez. Vagy tévedek?

A PHP-s alkalmazás komponens nálunk a közvetítő szerepét tölti be a vastag klienses alkalmazás és az EESZT között, és a SoapClient minden hibája ellenére a teszt EESZT környezethez gond nélkül tudunk is csatlakozni vele. Csak ehhez a rohadt éles környezethez nem, ami viszont "természetesen" 1 héttel az indulás előtt derült csak ki, mivel - ahogy írtam is - nekünk az éles rendszerhez nincs hozzáférésünk... No comment...

Válaszodat előre is köszönöm!
Üdv:

Dávid
11

Szia!Nem voltam alapos,

inf3rno · Okt. 31. (K), 00.49
Szia!

Nem voltam alapos, csak azt olvastam, hogy no SAML, és abból gondoltam, hogy az a hiba, közben meg ha jól látom az request location. Nem hiszem, hogy tudok segíteni nektek, bár újra átolvasom az egészet, hátha valami eszembe jut. Dolgoztam már évekkel ezelőtt PHP SoapClient-el, és nagyon rosszak a tapasztalataim vele. Ha megnézed a bug report-okat vele kapcsolatban, 10 éves hibák nincsenek javítva, olyan, mintha nem lenne egyáltalán karbantartva. Azt javaslom, hogy nagyon óvatosan bánjatok vele, és mindent ellenőrizzetek, hogy tényleg úgy működik e, ahogy le van írva a manual-ban, mert érhetnek meglepetések. Én ilyen esetben szoktam adaptert írni azokkal a dolgokkal, amiket használni fogok, aztán meg ahhoz teszteket, hogy tényleg minden követelményt teljesítenek e. Persze gondolom ennyi időtök nincsen.

Ha a teszt környezethez tudtok csatlakozni, akkor nem hiszem, hogy bármit tudtok tenni anélkül, hogy belenéznétek a logokba, hogy mivel van a probléma. Egyébként sajnálom, hogy 2017-ben SOAP-al kell foglalkoznotok, elég nagy egy hányadék az egész.
6

Kérdések

Pepita · Okt. 29. (V), 19.23
Ha azonban a kódot - kompletten, tanúsítványostul, WSDL-esektül - localhostból futtatjuk, akkor tudunk kapcsolódni a célszerverhez.
Az éles szolgáltatáshoz tudsz kapcsolódni saját gépedről?

- Mert ha igen, akkor csak a környezeti különbségek közül kell megtalálni, hogy mi a bibi, de nálatok van bibi valószínűleg.

- Ha nem, akkor kezdetnek azt javaslom, hogy egy valamilyen GUI klienssel teszteld le / beszélgess az éles klienssel. Ha nem sikerül, akkor őket kell zaklatnod, hogy miért nem.

Elsőhöz segítség: "A PHP verzióm a szerveren 5.3.3, localhoston pedig 5.5.12." Ez jó nagy különbség, utána kéne nézni, ezalatt mennyit változott a SoapClient.

Másodikhoz:
Webes teszt cucc (ez alap)
Letölthető kliens
Chrome extension boomerang
Még egy cucc
És ez is jó

A lényeg, hogy az ilyesmit mindig célszerű valamilyen kész klienssel megnézni előbb, "beszélgetni vele", és csak utána kódolni bármit is, mert ha kaptál is róla bármi doksit, abban is lehet elírás / tévedés, változtattak a szolgáltatáson és a doksi nem up to date, stb.
Egy ilyen klienssel az is kiderül, hogy a tanúsítványoddal műxik-e a dolog, vagy újat kell kérni / csináltatni.
Ha kézzel tudsz vele mindent beszélgetni, akkor ott is van előtted pontosan, hogy mit kell php-ben (vagy más nyelven) fejleszteni.

További javaslatok:
- Az igazi az, ha a dev és az éles környezet pontosan egyforma. Op. rendszer, adatbázisszerver, webszerver és php. Ini-kkel együtt persze. Ha az éles környezet csak vmi shared hosting, akkor is össze lehet szedni elég infót ahhoz, hogy ugyanazt összedobd mondjuk Docker alatt. Az nem baj, hardvere-t kevesebbet kap a dev, legalább hamarabb kiderül, ha valamit optimalizálni kell, bár jóval kevesebb request-et kell feldolgozni, mint élesben.
- Eddigiek alapján nem jöttem rá, hogy 1.1 vagy 1.2 a szolgáltatás verziója, azt látom, hogy te 1.1 - re állítod, de egy próbát megérne szerintem az 1.2. Itt azt mondják, hogy az eltérés hozhat ilyen hibát.
Ez is érdekes, főleg ha 5.3.11 előtti a php-d a szerveren.

(Váltsatok php 7.1.x-re ha tudtok, megéri.)
8

Kedves Pepita!Köszönöm,

tisch.david · Okt. 30. (H), 00.09
Kedves Pepita!

Köszönöm, hogy válaszoltál!

1. Igen, ha tokkal, vonóval letöltöm a fájlokat a gépemre és ott futtatom a kódot WAMP alatt, akkor tudok kapcsolódni az éles szolgáltatáshoz, föntről, a szerverről nem. Összehasonlítottam már a phpinfo()-kat, de elsőre nem találtam semmi ordító hiányt a szerveren, bár sajnos nem is vagyok a témának olyan nagy szakértője. Ha esetleg tudsz javasolni beállításokat, amiket érdemes ellenőrizni, akkor azt külön is megnézném. A tanúsítványkezelésben nem lehet eltérés a két környezet között, ha a két PEM ugyanaz? Nincs valami egyéb - pl. rendszer szintű - tanúsítvány, ami még belejátszat ebbe?

2. Igen, látom, hogy komoly hibákat javítottak a SOAP-ban az 5.3.3 és az 5.5.12 között, pl. az Általad is említett stream_context http header ignorálós hibát, bár - pro forma - ez minket most talán nem érint, nem? Vagy ki tudja, milyen disznóságok lapultak ennek a bugnak a mélyén? Mindenesetre megpróbálom frissíttetni a szerveren a PHP verziót, hátha segít.

3. Teljesen egyetértek Veled, a teszt rendszerhez való kapcsolódást is pontosan ugyanazon a szerveren, ugyanazzal a kóddal készítettem el, mint ahonnan és amivel az éles rendszerhez szerettem volna kapcsolódni, nehogy megszívassam magam. A gond csak az, hogy a teszt rendszernél viszont ragaszkodtak a fix IP-s eléréshez, ami miatt localhost-ból nem tudom tesztelni a teszt rendszerüket, a szerverről meg nem megy az éles - amihez hozzáférést csak 1 héttel az indulás előtt tudtunk "lopni" magunknak -, így nem tudok "kereszt" tesztet végezni.

4. Már próbáltam 1.2-es SOAP verzióval is, azzal se megy a szerverről az éles elérés.

5. Azt mondták, hogy az élesre való átállás csak egy URL átírását és egy tanúsítvány cserét fog jelenti. Az ÉLETEMET mertem volna feltenni arra, hogy nem lesz ez ilyen egyszerű. Aki ezt így találta ki, az egy agylövött barom.

Mégegyszer hálásan köszönöm a segítségedet!
Ha - a fentiek fényében - van még ötleted, akkor azt szívesen veszem!
Üdvözlettel:

Dávid
12

Rákérdeztem SO-n, mert nekem

inf3rno · Okt. 31. (K), 03.38
Rákérdeztem SO-n, mert nekem sem igazán volt tippem. Eddig semmi releváns. Egyébként cache kikapcsolása és tűzfal, amiket általában látni. Cert-el kapcsolatban ez jöhet esetleg szóba. SoapUI-t javasolják még, mint tesztelő eszközt, az jóval többet mond el a kapcsolódási hibákról elvileg. Aztán írnak még domain name resolution problem-et is, ami nekem baromi meglepő. Aztán olyat is írnak, hogy a kapcsolódási hibákat header-ben küldözgeti a SOAP, nem XML-ben, úgyhogy arrafelé érdemes keresgélni, ha valamivel el tudod kapni a header-eket. Szóval lehet ezer féle dolgot kipróbálni, de szerintem jobban jársz, ha következetesen kizárod az egyes részeket, mint hibaforrásokat az ötletelgetés helyett.

Az alapján, amit írtál, hogy máshonnan ugyanígy gond nélkül becsatlakozol, szerintem a szerver logok sem fognak megoldást nyújtani a problémádra, itt valami környezeti probléma lehet a háttérben, de ezt már írta Pepita is. Esetleg feltehetnétek egy másik WAMP-ot egy másik virtuális gépre a szerveren, hogy az becsatlakozik e. Lehetőleg teljesen ugyanazt, ami felcsatlakozott a saját gépedről is. Szóval előbb ott csinálj egy virtuális gépet, aztán ha az működik, akkor szórd fel ugyanazt a szerverre. Ha nem megy a szerverről, akkor valszeg nem a Debiannal vagy a PHP-vel lesz a gond, hanem a szerver és a webservice között akad meg a folyamat, tűzfalnál, proxy-nál, stb. Ha megy, akkor meg tovább lehet lépni olyan irányba, hogy az eredeti virtuális gépről megpróbálsz becsatlakozni más programnyelven, amiben nem bugos a SOAP kliens és nem kell hozzá apache, pl node-soap esetleg nginx-el, a lényeg, hogy kiváltsd az apache-ot és az az alatti részt. Utána tovább lehet lépni az apache-ra más nyelvvel, aztán a PHP-re SoapClient helyett cURL-el, és így tovább szűkíteni a kört, amíg nem találod meg, hogy honnantól kezdenek nem működni a dolgok. Erre talán rámegy egy nap is főleg ha nincs jogköröd hogy ezeket elintézd a szerveren, de mégis több értelme van, mint vaktában próbálkozni.

A SoapClient-el kapcsolatban még ami eszembe jutott közben, hogy amikor még sok éve azzal dolgoztam, akkor a nagy XML válaszokat nem tudta beparsolni, és kénytelen voltam kézzel megcsinálni. Erre érdemes odafigyelni, ha hosszú listákkal dolgoztok és még mindig megvan ez a bug.

SAML-ra találtam egy ilyet, bár az alapján, amit írtál, már készen vagytok mindennel, csak kapcsolódni nem sikerül.
14

Köszönet!!!

tisch.david · Okt. 31. (K), 11.42
Kedves Kollégák!

Hálásan köszönöm a sok-sok segítő hozzászólást! Külön köszönöm, inf3rno, ezt a hosszú válaszodat a végén!!

Képzeljétek, a végén mégiscsak BlaZe-nek lett "igaza": amikor megírtam nekik, hogy több, mint 60 felhasználó nem fog tudni csatlakozni az EESZT-hez határidőre, ha nem válaszolnak, rögtön válaszoltak! És kiderült, hogy még a logot se kell megnézniük, mert fejből nyomták, hogy már több probléma is volt abból, hogy a PROD rendszer TLSv1.2-t kényszerít, míg a DEV megengedte a TLSv1.0-t is, így a régebbi libcurl-t használó rendszerek nem tudnak csatlakozni a PROD-hoz. Értitek?! Erre vártunk 5 napot!!!

Most a szerver üzemeltetővel igyekszem frissíttetni a libcurl-t legalább az Általuk javasolt 7.54.0-ra, aztán nézünk egy új tesztet. curl-lel a következő paranccsal teszteltem a kapcsolatot, ami aztán elhasalt:
curl -v --tlsv1 https://if.eeszt.gov.hu/ESZIGEID/ESZIGEID_NO_SAML --cert cert.pem
Ha még lesz fejlemény, azt megírom. Nektek viszont ezer köszönet, hogy adtatok ötleteket és reményt a bajban! Így talán mégis meglesz a működő megoldás november 1-ig. Ja: és tartsátok távol Magatokat az állami fejlesztésű rendszerektől!

Üdv:

Dávid
15

Örülök, hogy megvan a

inf3rno · Okt. 31. (K), 16.58
Örülök, hogy megvan a megoldás!