Paano tumawag ng panloob na API mula sa app ng iPhone sa pamamagitan ng VPN

Sumasagot ang API sa Safari sa parehong telepono, habang nauubos ang oras ng kahilingan ng app. Ang agwat na iyon ay karaniwang hindi ang tunel: ang app na tumatawag sa isang panloob na serbisyo ay gumagawa ng ordinaryong kahilingang HTTPS, at ang umiiral nang VPN sa device ay nagpapasya lamang kung may landas ang kahilingang iyon. Ang magsulat ng pangalawang tunel sa app ay isang desisyon sa produkto, hindi isang pagkukumpuni para sa pagkaubos ng oras. Ang sumusunod ay inuuri ang kabiguan ayon sa kung saan ito nangyayari, gamit ang ibabaw ng mga error na mayroon na ang app.

Magsimula sa error, hindi sa tunel

URLSession ay nag-uulat ng mga kabiguan sa transportasyon bilang NSError mga halaga sa NSURLErrorDomain, at ang code ay ang pinakamurang ebidensiyang makukuha. Bago baguhin ang anumang pagkakaayos, i-log ang code na iyon kasama ang hostname na nabibigo at ang lumipas na oras ng gawain. Ang pagkaubos ng oras, kabiguan ng pangalan at kabiguan ng tiwala ay magkamukha sa screen at nangangailangan ng tatlong magkaibang pagkukumpuni. Uriin muna, pagkatapos ay basahin ang seksyon para sa klase na iyon.

Sinasagot ng mga sukatan ng gawain ang susunod na tanong, kung may naitatag na koneksyon, na naghihiwalay sa kahilingang walang landas kailanman mula sa isa na masyadong naantala ang server sa pagsagot. Wala sa mga ito ang nangangailangan ng pagbabago sa tunel; kailangan nitong i-print ang dayagnostiko ng kahilingan mismo sa lugar na mababasa mo.

Nabibigo ang resolusyon ng pangalan bago ang anupamang bagay

Ang maikling pangalan ng opisina tulad ng api.corp.example ay karaniwang nakadepende sa isang domain ng paghahanap na wala sa telepono, kaya nireresolba ng app ang isang pangalan na umiiral lamang sa loob ng gusali. NSURLErrorCannotFindHost ang lagda. Ang buong hostname ay dapat malutas sa pamamagitan ng anumang resolver na ikinakabit ng VPN, at dapat hilingin ng app ang ganap na kwalipikadong anyo kapag ang domain ng paghahanap ay hindi garantisado. Ang pagpapalit ng pangalan ng isang address at pagpatay sa mga pagsusuri ng sertipiko ay naglilipat ng kabiguan sa halip na ayusin ito.

Ang pribadong rekord ng DNS at sertipikong inisyu para sa eksaktong pangalang iyon ang sinusuportahang pares. Ang lahat ng iba ay isang paraan ng pag-iwas na nakararating sa mga gumagamit.

Ang pagkaubos ng oras ay tanong ng landas, hindi tanong ng pangalan

NSURLErrorTimedOut ay nangangahulugang nalutas ang pangalan at walang sumagot, na tumuturo sa ruta, patakaran ng packet o serbisyo. Kapag ang tunel ay itinalaga sa bawat aplikasyon, ang ibang app na nakakarating sa parehong server ay walang sinasabi tungkol sa iyong build, dahil hindi ibinabahagi ang mapping na iyon. Suriin na ang bundle na pinapatakbo mo ay nasa loob ng pagtatalagang iyon, pagkatapos ay suriin na ang landas ng serbisyo ay pinapayagan para dito. Ang build ng pagpapaunlad na naka-install sa labas ng pagtatalaga ay maaaring nasa labas ng tunel nang buo at magmukhang sirang API.

Ang paghahambing sa browser ay nagpapakita na may landas ang ilang app sa device. Hindi nito kailanman pinatutunayan na mayroon ang iyong build, kaya kailangang isagawa nang hiwalay ang dalawang pagsubok.

Ang mga kabiguan ng tiwala ay tungkol sa pangalan sa sertipiko

NSURLErrorServerCertificateUntrusted kasama ang error sa TLS sa ilalim nito ay nangangahulugang nabigo ang chain o ang pagsusuri ng pagkakakilanlan. Ang panloob na CA ay dapat pagkatiwalaan sa device, at ang sertipikong inisyu para sa ibang hostname ay mali pa rin pagkatapos ng anumang muling pagkakaayos ng network. Ang gabay sa App Transport Security ay patuloy na nalalapat sa mga koneksyong ito na naglo-load ng URL, at ang tunel sa paligid ng ordinaryong serbisyong HTTP ay hindi ginagawang ligtas ang serbisyong iyon mula sa dulo hanggang dulo.

Ayusin ang pagkakakilanlan o ang angkla ng tiwala at panatilihing walang laman ang listahan ng eksepsiyon. Ang pangkalahatang eksepsiyon para sa arbitraryong pag-load ay nagtatago ng kabiguan sa panahon ng pagpapaunlad at iniiwan ito sa lugar para sa bawat gumagamit pagkatapos.

Ang pagtanggi ng HTTP ay pag-aari ng app, hindi ng network

Ang 401 o 403 pagkatapos ng natapos na handshake ay nangangahulugang nakarating ang kahilingan at tinanggihan ito ng serbisyo, kaya ang natitirang tanong ay account, audience ng token, saklaw o key. I-log ang status code at hostname, hindi kailanman ang bearer token o ang katawan ng tugon. Sa puntong iyon ginagawa ng tunel ang trabaho nito, at ang karagdagang pagbabago sa network ay nagpapaliban lamang sa tunay na pagkukumpuni.

Ang talahanayan ang klasipikasyong dapat itago sa tabi ng terminal: isang hilera para sa bawat kabiguang talagang maaaring iulat ng app. I-print ang code bago mo ito basahin, dahil ang hilerang pipiliin mo ang magpapasya kung aling seksyon ang gagawin mo.

Ang bawat hilera ay mas murang subukan kaysa sa nasa ilalim nito, at bawat isa ay nag-aalis ng ibang layer ng parehong kahilingan. Bumaba sa talahanayan hanggang may tumugmang hilera, pagkatapos ay itigil ang pagbabago sa network.