Skrip auth-user-pass-verify OpenVPN: kod keluar yang betul

OpenVPN bertindak atas tepat satu output daripada skrip log masuk: status keluar. Semua perkara lain yang dilakukan skrip hanyalah hiasan. Hook boleh sampai ke pengesah yang betul, menghurai respons dan mencetak baris mesra sambil mengembalikan status yang bermaksud sebaliknya daripada hasrat penulisnya. Baca kontrak dahulu dan tulis penyesuai di sekelilingnya, dan seluruh kelas pepijat itu hilang.

Kontraknya kecil: kenal pasti akaun yang dihantar, tanya pengesah yang diluluskan soalan yang dimaksudkan dan terima hanya hasil positif berdokumen pengesah itu untuk permintaan tersebut. Semua yang lain ialah infrastruktur.

Tiga status yang boleh dikembalikan oleh hook

Untuk auth-user-pass-verify, manual OpenVPN 2.6 mentakrifkan kod keluar 0 sebagai penerimaan, 1 sebagai penolakan dan 2 sebagai pengesahan tertunda. Itulah satu-satunya tiga jawapan yang difahami pelayan, dan setiap satu mempunyai akibat berbeza untuk sambungan. Skrip yang keluar dengan status arahan terakhirnya sebenarnya telah membiarkan panggilan log atau langkah pembersihan mengundi. Tulis status secara eksplisit dalam setiap cabang, termasuk cabang yang tidak pernah sampai ke pengesah.

Kejayaan HTTP dan kejayaan pengesahan ialah lapisan berasingan, dan mengelirukan kedua-duanya ialah cara paling biasa hook ini salah. Respons 202 bermaksud permintaan telah diterima untuk diproses, bukan bahawa kata laluan telah disahkan. Takrifkan status jangkaan, bentuk respons dan keputusan akhir daripada kontrak API yang diberikan kepada anda, dan jangan cipta nama medan kerana ia kelihatan munasabah.

Jika jawapan benar-benar tiba kemudian, itulah laluan tertunda dan ia mesti dibina sedemikian. Percubaan tertunda yang tidak pernah diselesaikan menahan sumber sehingga had masa tamat.

Baca fail kelayakan tepat seperti yang ditulis

Dengan kaedah melalui fail yang berdokumen, pelayan menulis nama pengguna dan kata laluan sebagai dua baris pertama fail sementara, menyerahkan laluan itu kepada skrip dan membuang fail itu apabila skrip kembali. Baca kedua-dua baris itu sebagai data: jangan sekali-kali source fail itu, jangan sekali-kali menilainya, dan jangan sekali-kali menampal kandungannya ke dalam baris arahan tempat jadual proses boleh melihatnya. Kekalkan kata laluan bait demi bait, kerana menormalkannya seperti anda menormalkan nama pengguna secara senyap mengubah kelayakan itu. Direktori untuk fail sementara itu ialah keputusan penggunaan, jadi pastikan ia wujud dan tidak boleh dibaca oleh semua orang pada hos.

Asingkan kelayakan pengesah itu sendiri daripada kelayakan pengguna: ia milik integrasi gerbang, tinggal dalam stor rahsia platform dan hanya memerlukan kebenaran untuk mengesahkan, jadi ia bukan bukti bahawa mana-mana orang tertentu telah disahkan. Jangan biarkan hook menjadi pengesah kata laluan kedua juga. Menulis semula perbandingan cincangan secara manual tidak menjadi selamat dengan mengoptimumkan gelung, dan pengesah yang diselenggara sudah memahami skema bergaram dan berkos yang ada pada stor akaun.

Tentukan apa maksud jawapan yang tidak dapat dikelaskan

Had masa, ralat pengangkutan, respons cacat dan backend yang tidak tersedia berkongsi satu sifat: tiada satu pun daripadanya ialah pengesahan positif. Hook harus gagal tertutup bagi setiap satu daripadanya dan merekod sebab yang boleh diambil tindakan oleh pengendali. Sebab itu terletak dalam log yang dilindungi, bukan dalam mesej yang dipulangkan kepada orang yang cuba menyambung.

Berhati-hati sama rata dengan laluan yang langsung tidak sampai ke pengesah. Nilai konfigurasi yang hilang, rahsia yang tidak boleh dibaca atau kebergantungan yang tidak dipasang sepatutnya menghasilkan penolakan dengan penanda operasi yang tersendiri dan bukan penerimaan tidak sengaja. Uji cabang itu dengan membuang kebergantungan dalam makmal dan bukannya membuat penaakulan tentangnya. Di mana kegagalan untuk log boleh mengubah status keluar, log telah menjadi sebahagian daripada keputusan dan mesti dijadikan tidak berbahaya.

Konfigurasi pelayan juga penting di sini: skrip yang ditentukan pengguna hanya dihormati apabila konfigurasi yang berjalan membenarkannya pada tahap keselamatan yang diperlukan, dan tetapan itu ialah pilihan yang disengajakan dan bukan nilai lalai yang perlu dinaikkan.

Sahkan keputusan, bukan baris yang dicetak

Bina ujian yang memeriksa status keluar secara langsung. Tulis fail kelayakan contoh, jalankan hook terhadapnya dengan akaun yang diketahui baik dan akaun yang diketahui buruk, dan baca status yang dilaporkan oleh shell dan bukan teks yang dicetak oleh skrip. Semakan tunggal itu menangkap kebanyakan pepijat kontrak sebelum klien sempat menyambung.

Kemudian jalankan kes yang sama melalui klien sebenar terhadap pendengar bukan pengeluaran dan sahkan apa yang direkodkan oleh pelayan: diterima, ditolak atau tertunda. Liputi akaun yang dilumpuhkan, kata laluan yang salah, respons pengesah yang cacat, had masa dan pengesah yang tidak dapat dicapai. Jika mana-mana kes berakhir dalam keadaan yang anda tidak dapat namakan, penyesuai itu belum selesai.

Simpan pemetaan daripada hasil pengesah kepada status keluar di sebelah skrip dalam repositori, supaya jurutera seterusnya boleh membaca kontrak tanpa membuat kejuruteraan songsang kod.