Gesaan dan skop
Klien perkhidmatan mencapai API luaran melalui beberapa proksi eksplisit. Sesetengah permintaan mengembalikan 407 dan yang lain 401. Terangkan sempadan antara kedua-duanya, cabaran proksi hop-by-hop, terowong CONNECT, penyimpanan kelayakan, percubaan semula dan kebolehmerhatian.
Ini ialah soalan rangkaian dan keselamatan backend. Bilangan proksi dan kadar kegagalan adalah andaian untuk latihan ini, bukan tuntutan pasaran.
Perkara yang diuji oleh penemu duga
- Sama ada anda memisahkan pengesahan pelayan sumber daripada pengesahan proksi hop seterusnya.
- Sama ada anda menerangkan tempat
Proxy-AuthenticatedanProxy-Authorizationdigunakan. - Sama ada anda mengendalikan pelbagai hop, CONNECT, kolam sambungan dan giliran kelayakan.
- Sama ada kelayakan proksi kekal jauh daripada sumber (origin) dan log.
Soalan penjelasan untuk ditanya
- Adakah klien menggunakan proksi eksplisit atau telus, dan adakah CONNECT terlibat?
- Skim manakah yang digunakan oleh setiap proksi, dan adakah sambungan diguna semula?
- Bolehkah klien dan get laluan mengekalkan pengepala 401 dan 407 yang asal?
- Adakah permintaan itu bacaan selamat atau adakah ia mencipta, mengenakan caj atau mengubah keadaan?
- Siapakah yang menggilirkan kelayakan, dan adakah proksi keluar sandaran tersedia?
Jawapan 30 saat
"407 ialah cabaran daripada proksi hop seterusnya; 401 adalah daripada sumber sasaran. Saya merekodkan pengecam hop dan permintaan, membaca Proxy-Authenticate, dan menghantar Proxy-Authorization yang sepadan hanya kepada proksi tersebut. Proksi masuk seterusnya menggunakannya; ia tidak boleh sampai ke sumber (origin). Untuk CONNECT, sahkan proksi sebelum mencipta terowong, kemudian kendalikan 401 peringkat terowong sebagai pengesahan sumber. Saya mencuba semula hanya permintaan yang selamat dimainkan semula dan mengukur 407 mengikut proksi, skim dan versi kelayakan."
Reka bentuk langkah demi langkah
1. Pisahkan 401 dan 407
WWW-Authenticate dalam 401 menerangkan cabaran sumber sasaran, biasanya dijawab dengan Authorization. Proxy-Authenticate dalam 407 menerangkan cabaran daripada proksi hop seterusnya, dijawab dengan Proxy-Authorization. Nombor status yang serupa tidak mewajarkan perkongsian cache atau satu pengendali ralat.
2. Sahkan satu hop pada satu masa
Setiap proksi hanya menerima kelayakan yang dimintanya. RFC 9110 mentakrifkan Proxy-Authorization untuk proksi masuk seterusnya yang menuntutnya; dalam rantaian, proksi pertama yang menjangkakan kelayakan akan menggunakan medan tersebut. Klien mengasingkan kelayakan mengikut proksi atau sambungan dan tidak sekali-kali memajukan pengepala proksi kepada sumber (origin).
GET https://api.example/report HTTP/1.1
Host: api.example
Proxy-Authorization: Basic <proxy-credential>3. Kendalikan terowong CONNECT
Untuk sasaran HTTPS, klien menghantar CONNECT kepada proksi terlebih dahulu. Selepas pengesahan proksi berjaya dan proksi mengembalikan 2xx, klien mencipta terowong TLS. Permintaan di dalamnya adalah milik sumber (origin); 401 sumber menggunakan Authorization dan tidak disalah anggap sebagai 407 proksi. Cabaran proksi yang gagal masih milik hop CONNECT.
4. Asingkan kolam dan kelayakan
Kunci kolam merangkumi alamat proksi, skim pengesahan, penyewa (tenant) dan versi kelayakan. Semasa penggilan, berhenti menggunakan semula sambungan lama atau sahkan semula seperti yang diperlukan oleh proksi. Jangan letakkan Proxy-Authorization dalam templat pengepala rentas permintaan atau rekod nilainya dalam sistem penjejakan (tracing).
5. Hadkan percubaan semula dan kesan sampingan
Selepas 407, cuba semula hanya apabila tiada badan (body) yang tidak boleh dipulihkan telah dihantar atau operasi itu selamat untuk dimainkan semula. Untuk POST, pengecasan atau penciptaan sumber, gunakan kunci ketakbolehubahan (idempotency key) perniagaan dan semak sama ada pelayan telah memproses percubaan tersebut. Pengendalian cabaran, penyegaran kelayakan dan main semula hendaklah menjadi peristiwa yang boleh diperhatikan, bukan gelung tanpa had.
6. Instrumen diagnosis dan keselamatan
Bagi setiap hop, rekodkan identiti proksi, fasa CONNECT, skim, versi kelayakan, kiraan 407, hasil percubaan semula dan status akhir; simpan ringkasan yang telah disunting sahaja. Bandingkan 401, 407, kegagalan TLS, penggunaan semula kolam dan pertukaran keluar sandaran untuk mengesan kerosakan sasaran, dasar proksi atau giliran kelayakan. Suntik kegagalan untuk membuktikan bahawa perantara tidak boleh membocorkan atau menulis semula pengepala kebenaran sumber.
Model jawapan berkualiti tinggi
"Saya membahagikan laluan kepada lapisan proksi dan sumber. Proksi seterusnya mencabar dengan 407 dan sumber mencabar dengan 401, masing-masing menggunakan Proxy-Authorization dan Authorization. Kelayakan diasingkan mengikut identiti proksi; proksi masuk pertama yang menjangkakan medan proksi akan menggunakannya, dan ia tidak pernah sampai ke sumber. HTTPS mengesahkan proksi semasa CONNECT sebelum trafik terowong. Kolam dipisahkan mengikut proksi dan versi kelayakan, dan giliran melupuskan sambungan lama. Hanya permintaan selamat dimainkan semula selepas 407; kesan sampingan dipulihkan dengan ketakbolehubahan (idempotency) dan pertanyaan status. Metrik peringkat hop mengenal pasti kerosakan."
Kesilapan biasa
- Memperlakukan 407 sebagai 401 → kelayakan melintasi sempadan yang salah → kendalikan cabaran proksi dan sumber secara berasingan.
- Memajukan kelayakan proksi kepada sumber → rahsia bocor → biarkan proksi masuk seterusnya menggunakan dan mengeluarkannya.
- Menghantar trafik terowong sebelum CONNECT berjaya → keadaan protokol tidak betul → selesaikan pengesahan proksi dan terima CONNECT 2xx terlebih dahulu.
- Berkongsi semua keadaan pengesahan sambungan → penyewa atau versi kelayakan bercampur aduk → asingkan mengikut proksi, penyewa dan versi.
- Mencuba semula 407 selama-lamanya → kerosakan dan kesan sampingan bertambah teruk → hadkan percubaan, uji keselamatan main semula dan buat pertanyaan status.
Soalan susulan dan jawapan
Bolehkah saya menghantar beberapa nilai Proxy-Authorization untuk beberapa proksi?
Jangan layan medan tersebut sebagai senarai kelayakan generik. Hantar apa yang dijangkakan oleh proksi masuk semasa; selepas ia menggunakan medan tersebut, kendalikan cabaran kemudian mengikut skim hop tersebut dan sahkan bahawa pelaksanaan membenarkan pemajuan yang selamat.
Mengapa tidak mendiagnosis daripada 407 terakhir sahaja?
Get laluan boleh menulis semula atau menelan respons perantaraan, dan penggunaan semula sambungan boleh melampirkan cabaran pada permintaan yang salah. Simpan log hop, pengecam sambungan dan cabaran asal untuk mengenal pasti pengeluar sebenar.
Bagaimana jika pengesahan proksi berjaya tetapi terowong mengembalikan 401?
Kekalkan keadaan pengesahan proksi dan jawab cabaran WWW-Authenticate sumber dengan Authorization. Jangan hantar semula kelayakan proksi atau letakkan kelayakan sumber dalam cache pengesahan proksi.