Skrip auth-user-pass-verify OpenVPN: kode keluar yang benar

OpenVPN bertindak berdasarkan tepat satu keluaran dari skrip login: status keluar. Semua hal lain yang dilakukan skrip hanyalah hiasan. Hook bisa mencapai verifier yang benar, mengurai respons, dan mencetak baris yang ramah sambil mengembalikan status yang berarti kebalikan dari maksud penulisnya. Baca kontraknya lebih dulu dan tulis adaptor di sekitarnya, dan seluruh kelas bug itu hilang.

Kontraknya kecil: identifikasi akun yang dikirim, ajukan pertanyaan yang dimaksud kepada verifier yang disetujui, dan terima hanya hasil positif terdokumentasi dari verifier itu untuk permintaan tersebut. Sisanya adalah infrastruktur.

Tiga status yang dapat dikembalikan hook

Untuk auth-user-pass-verify, manual OpenVPN 2.6 mendefinisikan kode keluar 0 sebagai penerimaan, 1 sebagai penolakan, dan 2 sebagai autentikasi tertunda. Itulah satu-satunya tiga jawaban yang dipahami server, dan masing-masing punya konsekuensi berbeda bagi koneksi. Skrip yang keluar dengan status perintah terakhirnya sebenarnya membiarkan panggilan log atau langkah pembersihan ikut memutuskan. Tulis status secara eksplisit di setiap cabang, termasuk cabang yang tidak pernah mencapai verifier.

Keberhasilan HTTP dan keberhasilan autentikasi adalah lapisan terpisah, dan mencampurnya adalah cara paling umum hook ini salah. Respons 202 berarti permintaan diterima untuk diproses, bukan bahwa kata sandi telah diverifikasi. Tetapkan status yang diharapkan, bentuk respons, dan putusan akhir dari kontrak API yang Anda terima, dan jangan mengarang nama bidang karena tampak masuk akal.

Jika jawabannya benar-benar datang belakangan, itulah jalur tertunda dan harus dibangun seperti itu. Percobaan tertunda yang tidak pernah selesai menahan sumber daya sampai batas waktu berakhir.

Baca file kredensial persis seperti yang tertulis

Dengan metode via-file yang terdokumentasi, server menulis nama pengguna dan kata sandi sebagai dua baris pertama file sementara, meneruskan jalur itu ke skrip, dan menghapus file saat skrip kembali. Baca kedua baris itu sebagai data: jangan pernah menjalankan source pada file, jangan pernah mengevaluasinya, dan jangan pernah menempelkan isinya ke baris perintah tempat tabel proses dapat melihatnya. Pertahankan kata sandi byte demi byte, karena menormalisasinya seperti Anda menormalisasi nama pengguna diam-diam mengubah kredensial. Direktori untuk file sementara itu adalah keputusan penerapan, jadi pastikan direktori itu ada dan tidak dapat dibaca oleh semua orang di host.

Pisahkan kredensial milik verifier dari milik pengguna: kredensial itu milik integrasi gateway, tinggal di penyimpanan rahasia platform, dan hanya perlu izin memverifikasi, jadi bukan bukti bahwa orang tertentu telah terautentikasi. Jangan biarkan hook menjadi verifier kata sandi kedua juga. Menulis ulang perbandingan hash dengan tangan tidak menjadi aman dengan mengoptimalkan loop, dan verifier yang terpelihara sudah memahami skema bergaram dan berbiaya dari penyimpanan akun.

Putuskan apa arti jawaban yang tidak dapat diklasifikasikan

Batas waktu, kesalahan transportasi, respons cacat, dan backend yang tidak tersedia berbagi satu sifat: tidak satu pun merupakan verifikasi positif. Hook harus gagal tertutup untuk masing-masing dan mencatat alasan yang dapat ditindaklanjuti operator. Alasan itu tempatnya di log yang dilindungi, bukan di pesan yang dikembalikan kepada orang yang mencoba terhubung.

Sama berhati-hatilah dengan jalur yang sama sekali tidak mencapai verifier. Nilai konfigurasi yang hilang, rahasia yang tidak terbaca, atau dependensi yang tidak terpasang harus menghasilkan penolakan dengan penanda operasional yang berbeda alih-alih penerimaan yang tidak disengaja. Uji cabang itu dengan menghapus dependensi di laboratorium alih-alih menalar tentangnya. Jika kegagalan mencatat log dapat mengubah status keluar, pencatatan log telah menjadi bagian dari keputusan dan harus dibuat tidak berbahaya.

Konfigurasi server juga penting di sini: skrip yang ditentukan pengguna hanya dihormati ketika konfigurasi yang berjalan mengizinkannya pada tingkat keamanan yang diperlukan, dan pengaturan itu adalah pilihan yang disengaja, bukan nilai bawaan yang perlu dinaikkan.

Verifikasi putusannya, bukan baris yang dicetak

Bangun pengujian yang memeriksa status keluar secara langsung. Tulis file kredensial contoh, jalankan hook terhadapnya dengan akun yang diketahui baik dan akun yang diketahui buruk, lalu baca status yang dilaporkan shell, bukan teks yang dicetak skrip. Satu pemeriksaan itu menangkap sebagian besar bug kontrak sebelum klien sempat terhubung.

Lalu jalankan kasus yang sama melalui klien sungguhan terhadap listener non-produksi dan pastikan apa yang dicatat server: diterima, ditolak, atau ditunda. Cakup akun yang dinonaktifkan, kata sandi salah, respons verifier yang cacat, batas waktu, dan verifier yang tidak dapat dijangkau. Jika ada kasus yang berakhir pada keadaan yang tidak dapat Anda beri nama, adaptor belum selesai.

Simpan pemetaan dari hasil verifier ke status keluar di samping skrip dalam repositori, agar insinyur berikutnya dapat membaca kontrak tanpa merekayasa balik kode.