WordPress tenas sian propran retejon ekster la prokurilo

WP_PROXY_HOST kaj WP_PROXY_PORT estas agorditaj. Peto al ekstera API uzas la prokurilon, sed peto reen al la propra hostnomo de WordPress ne. Tio povas esti la intencita ĉirkaŭira politiko de la HTTP-API.

WP_HTTP_Proxy decidas ĉu aparta URI devas pasi tra la prokurilo. Ĝia defaŭlta logiko preterpasas localhost kaj la hostnomon derivitan de la agordita siteurl de la retejo. Tio estas aparta de simple decidi ĉu prokurilaj konstantoj ekzistas.

Ekzamenu la URL-on, kiun WordPress taksis

Tenu kune la petitan hostnomon, la agorditan retejan URL-on kaj WP_PROXY_BYPASS_HOSTS. Peto al publika hostnomo kaj peto al interna kromnomo povas fari malsamajn decidojn eĉ se ambaŭ atingas la saman aplikaĵon.

WP_PROXY_BYPASS_HOSTS aldonas agorditan liston da hostaj esceptoj. Ĝi ne estas aro da celoj permesataj de la fora prokurilo, kaj ĝi ne ebligas alie blokitan eksteran peton.

La defaŭlta escepto de la propra retejo povas esti utila: ĝi evitas sendi lokan aplikaĵan peton de loopback-tipo al peranto. Sed instalado, en kiu la publika hostnomo de la retejo estas atingebla nur per aparta aprobita vojo, eble bezonas alian konscian decidon.

Ŝanĝu la decidon ĉe la subtenata hoko

La filtrilo pre_http_send_through_proxy povas anstataŭigi la decidon por ĉiu URI. Tenu ĉiun anstataŭigon mallarĝa kaj agordu ĝin al la hostnomo aŭ kondiĉo, kiun ĝi devas trakti. Redoni unu fiksan respondon por ĉiu URI ŝanĝas la politikon de la tuta HTTP-API.

Ekzamenu ankaŭ la elektitan transporton. Kodo, kiu vokas apartan SDK-on aŭ krudan PHP-retfunkcion, ne aŭtomate uzas la HTTP-API de WordPress kaj ĝian filtrilon.

Kiam vi diagnozas tiun ĉi vojon, registru la ĉirkaŭiran decidon sen publikigi plenajn petajn argumentojn. Ili povas enhavi kuketojn, kontoinformojn kaj prokurilajn sekretojn. Prokurila protokolo sen kongrua peto kongruas kun ĉirkaŭiro, sed ĝi sola ne sufiĉas por distingi ĝin de peto neniam farita.