Saya ingin memfilter setiap permintaan HTTP yang dilakukan URI melalui API HTTP.
Gunakan kasing:
- Pemeriksaan pembaruan WordPress masuk ke http://api.wordpress.org/core/version-check/1.6/ , tetapi https://api.wordpress.org/core/version-check/1.6/ juga berfungsi, dan saya ingin untuk menggunakan ini selalu.
- File WordPress baru diambil dari http://wordpress.org/wordpress-3.4.2.zip , tetapi https://wordpress.org/wordpress-3.4.2.zip juga berfungsi.
- Terkadang saya ingin men-debug permintaan dan mengarahkan mereka yang sementara ke domain khusus di server lokal saya.
- Beberapa plugin membuat permintaan ke server lain, dan saya ingin mengganti permintaan ini ketika server eksternal turun.
Permintaan pembaruan adalah yang paling penting untuk saat ini, karena masih ada bug yang belum diperbaiki 16778 ( informasi lebih lanjut ), dan permintaan HTTPS menurunkan risiko serangan Man-in-the-middle.
Saya telah mencari dengan seksama , saya telah mempelajari kode inti ... tetapi akhirnya seperti Nacin dua tahun lalu:
Saya yakin Anda dapat memfilter URL permintaan HTTP, tetapi sekarang saya tidak dapat menemukannya.
Apa yang saya lewatkan? Benarkah? :)
Jawaban:
Kurang dari jawaban, tetapi hanya daftar hal-hal langsung dari pengalaman saya dengannya - mungkin Anda telah mengabaikan sesuatu.
Men-debug permintaan & hasilnya
Tanpa diggin terlalu jauh ke dalam proses pembaruan, tetapi WP HTTP API menggunakan
WP_HTTP
kelas. Ini juga menawarkan hal yang menyenangkan: Sebuah kait debug.Di mana
$response
juga bisa menjadiWP_Error
objek yang mungkin memberi tahu Anda lebih banyak.Catatan: Dari tes singkat, filter ini tampaknya hanya (karena alasan tertentu) berfungsi jika Anda menempatkannya sedekat mungkin dengan tempat Anda benar-benar melakukan permintaan. Jadi mungkin Anda perlu meneleponnya dari dalam panggilan balik di salah satu filter di bawah ini.
WP_HTTP
Argumen kelasArgumen Classes itu sendiri dapat difilter, tetapi beberapa afaik mendapatkan reset dengan metode internal kembali ke apa WP menganggap bahwa diperlukan.
Salah satu argumennya adalah
ssl_verify
, yang benar secara default (tetapi bagi saya menyebabkan masalah besar ketika memperbarui dari - misalnya - GitHub). Sunting: Setelah men-debug permintaan pengujian, saya menemukan argumen lain yang ditetapkan untuk memverifikasi jika SSL diatur ketrue
. Ini disebutsslverify
(tanpa memisahkan garis bawah). Tidak tahu di mana ini datang ke dalam permainan, apakah itu benar-benar digunakan atau ditinggalkan dan jika Anda memiliki kesempatan untuk mempengaruhi nilainya. Saya menemukannya menggunakan'http_api_debug'
filter.Sepenuhnya kustom
Anda juga dapat "cukup" menimpa seluruh internal dan pergi dengan pengaturan khusus. Ada filter untuk itu.
Arg pertama harus di set true. Daripada Anda dapat berinteraksi dengan argumen di dalam
$r
dan hasil dariparse_url( $url );
.Proksi
Hal lain yang mungkin berhasil adalah menjalankan semuanya melalui Proxy khusus. Ini membutuhkan beberapa pengaturan di
wp-config.php
. Saya belum pernah mencoba ini sebelumnya, tetapi saya berlari melalui konstanta beberapa waktu lalu dan menyimpulkan beberapa contoh yang harus bekerja dan menyertakan beberapa komentar jika saya membutuhkannya suatu hari. Anda harus mendefinisikanWP_PROXY_HOST
danWP_PROXY_PORT
sebagai min. pengaturan. Jika tidak, tidak ada yang akan bekerja dan itu hanya akan memotong proxy Anda.EDIT
The
WP_HTTP
Kelas biasanya bertindak sebagai basis kelas (akan diperpanjang untuk skenario yang berbeda). The memperpanjangWP_HTTP_*
kelas yangFsockopen
,Streams
,Curl
,Proxy
,Cookie
,Encoding
. Jika Anda mengaitkan panggilan balik ke'http_api_debug'
-aksi, maka argumen ketiga akan memberi tahu Anda kelas mana yang digunakan untuk permintaan Anda.Di dalam
WP_HTTP_curl
Kelas, Anda akan menemukanrequest()
metodenya. Metode ini menawarkan dua filter untuk mencegat perilaku SSL: Satu untuk permintaan lokal'https_local_ssl_verify'
dan satu untuk permintaan jarak jauh'https_ssl_verify'
. WP kemungkinan akan mendefinisikanlocal
sebagailocalhost
dan apa yang Anda dapatkan sebagai imbalannyaget_option( 'siteurl' );
.Jadi yang akan saya lakukan adalah mencoba yang berikut sebelum Anda melakukan permintaan itu (atau dari panggilan balik yang terhubung ke permintaan terdekat:
Sidenote: Dalam kebanyakan kasus
WP_HTTP_curl
akan digunakan untuk menangani Proxy.sumber
pre_http_request
, membatalkan permintaan dan mengirimnya kembali dengan URL yang benar. Akan mencobanya malam ini.Berdasarkan jawaban berguna @ kaiser saya telah menulis beberapa kode yang sepertinya berfungsi dengan baik. Itulah alasan mengapa saya menandainya sebagai Jawaban.
Biarkan saya jelaskan solusinya ...
Logika
Ketika permintaan itu dikirim melalui API dijalankan
WP_Http::request()
. Itulah metode dengan ...... di tajuknya. Saya sangat setuju.
Sekarang, ada beberapa filter. Saya memutuskan untuk menyalahgunakan
pre_http_request
kebutuhan saya:Kami mendapatkan tiga argumen di sini:
false, $r, $url
.false
adalah nilai pengembalian yang diharapkan untukapply_filters()
. Jika kami mengirim apa pun kembali, WordPress segera berhenti, dan permintaan asli tidak akan dikirim.$r
adalah array argumen untuk permintaan itu. Kita harus mengubahnya juga dalam semenit.$url
adalah - kejutan! - URL.Jadi dalam panggilan balik
t5_update_wp_per_https()
kami, kami melihat URL, dan jika itu URL yang ingin kami filter, kami katakan TIDAK ke WordPress dengan tidak mengatakan "tidak" (false
).Catatan: Ini mengikuti Anda dapat mencegah semua permintaan HTTP dengan:
add_filter( 'pre_http_request', '__return_true' );
Kami malah memecat permintaan kami sendiri dengan URL yang lebih baik dan argumen yang sedikit disesuaikan (
$r
, diganti namanya menjadi$args
agar mudah dibaca).Kode
Silakan baca komentar sebaris, itu penting.
Tes
Tanpa plugin yang digunakan WordPress:
http://api.wordpress.org/core/version-check/1.6/
untuk memeriksa pembaruan, danhttp://wordpress.org/wordpress-3.4.2.zip
untuk mengunduh file baru.Saya diuji dengan dua instalasi lokal, satu situs dan multi-situs setup pada Win 7. Untuk memaksa update saya set
$wp_version
diwp-includes/version.php
ke1
dan versi TwentyEleven untuk1.3
.Untuk menonton lalu lintas jaringan saya menggunakan Wireshark : Ini gratis, ini berjalan pada Windows dan Linux, dan ia menawarkan beberapa alat penyaring yang mengesankan.
Menonton HTTPS sedikit sulit: Anda hanya melihat data terenkripsi ... itu idenya. Untuk melihat apakah plugin saya melakukan apa yang harus dilakukan, saya menonton lalu lintas yang tidak terenkripsi terlebih dahulu dan mencatat alamat IP yang digunakan untuk terhubung ke wordpress.org. Itu
72.233.56.138
, kadang-kadang72.233.56.139
.Tidak mengherankan, ada penyeimbang beban dan mungkin banyak alat lainnya, jadi kami tidak bisa mengandalkan satu alamat IP.
Lalu saya mengetik
ip.addr == 72.233.56.138
ke filter mask, mengaktifkan plugin, pergi kewp-admin/update-core.php
dan mengawasi lalu lintas di Wireshark. Garis hijau adalah permintaan dalam teks biasa - persis apa yang tidak kita inginkan. Garis merah dan hitam adalah tanda keberhasilan.Pemeriksaan pembaruan berjalan dengan baik: Ditemukan versi "lebih baru". Pembaruan aktual untuk tema dan intinya berjalan dengan baik juga. Apa yang saya butuhkan.
Dan masih ... itu bisa lebih mudah jika ada filter sederhana untuk URL.
sumber
/* /**/
, hanya karena itu jenius. Dan (jika saya bisa) +1 lain untuk Charles Bronson. Dan kemudian harus ada +1 lain untuk penjelasan terperinci, komentar & tangkapan layar.sumber