Petunjuk dan konteks
Tim menginginkan URI Template untuk dokumentasi API, tautan paginasi, dan URL kueri batch seperti /users{?status,limit}. Template berasal dari konfigurasi sementara beberapa nilai variabel berasal dari pengguna. Jelaskan tingkat ekspresi RFC 6570, ekspansi karakter khusus dan daftar (list), serta batas keamanan untuk mengurai, mengekspansi, dan memvalidasi hasilnya.
Apa yang sedang diuji oleh pewawancara
- Memisahkan sintaksis template, encoding variabel, serta penguraian dan validasi URI akhir.
- Menjelaskan perbedaan antara ekspansi sederhana, reserved, path, parameter matriks, dan kueri.
- Menangani daftar, peta asosiatif, explode, pemotongan prefiks, dan variabel yang tidak terdefinisi.
- Mengenali risiko SSRF, path traversal, open redirect, dan kebocoran data dari template yang tidak tepercaya.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah template berupa kode statis, konfigurasi yang ditinjau, atau disediakan oleh tenant/pengguna?
- Apakah hasilnya hanya ditampilkan, atau dikirim langsung oleh klien HTTP sisi server?
- Apakah variabel berupa string, daftar, peta asosiatif, atau JSON bersarang?
- Skema, host, port, dan prefiks path mana yang diizinkan; apakah hasilnya harus tetap berada pada origin API saat ini?
- Apakah implementasi harus mendukung semua tingkat RFC 6570, atau hanya subset operator yang disetujui?
Kerangka jawaban 30 detik
Saya akan memisahkan penguraian template, encoding variabel, dan kebijakan URI akhir. Pertama, tentukan operator dan tipe nilai RFC 6570 yang didukung, lalu terapkan percent-encoding, ekspansi daftar, dan peta asosiatif per operator; variabel yang tidak terdefinisi harus diabaikan sesuai spesifikasi. Perlakukan setiap nilai yang diekspansi sebagai URI yang tidak tepercaya, urai dan validasi skema, host, port, dan path yang dinormalisasi, serta jangan pernah membiarkan template memilih target jaringan sisi server yang sembarangan. Pengujian akan mencakup karakter khusus, Unicode, nilai kosong, kunci berulang, prefiks, dan path berbahaya.
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan batas URI Template
URI Template adalah sintaksis untuk mengekspresikan referensi URI dengan variabel. Ini bukan klien HTTP, allowlist URL, atau router bisnis. Implementasi harus mengurai literal dan ekspresi sebelum menghasilkan hasil dari nilai; implementasi tidak boleh menggabungkan template ke dalam permintaan atau memperlakukan nilai yang diekspansi sebagai URL yang sudah aman.
Langkah 2: Terapkan operator berdasarkan tingkatan
RFC 6570 dimulai dengan ekspansi variabel sederhana dan menambahkan bentuk karakter khusus, fragmen, label, segmen path, parameter matriks, kueri, dan kelanjutan kueri. Operator umum meliputi +, #, ., /, ;, ?, dan &. Operator menentukan pemisah, perilaku nilai kosong, dan karakter khusus mana yang boleh tetap ada; satu aturan penggantian string generik saja tidak cukup.
Langkah 3: Tangani encoding dan nilai komposit
Karakter khusus dalam string sederhana di-percent-encode sesuai dengan ekspresi. Daftar dapat digabungkan dengan koma atau di-explode menjadi parameter yang berulang; peta asosiatif memiliki pemisah kunci/nilai sendiri. Pengubah prefiks mengambil prefiks string dan tidak boleh disalahartikan sebagai jumlah karakter Unicode, jumlah byte, atau pemotongan yang aman. Tentukan perilaku untuk UTF-8, string kosong, dan variabel yang tidak terdefinisi.
Langkah 4: Isolasi sumber template dan variabel
Template statis yang ditinjau kodenya dapat mendukung lebih banyak operator; konfigurasi tenant harus membatasi ekspresi, nama variabel, dan komponen output. Nilai dapat berasal dari permintaan, tetapi template tidak boleh memanggil fungsi, membaca variabel lingkungan, atau menyusun skema yang sembarangan. Pisahkan AST template dari peta nilai sehingga nama variabel tidak dapat menyuntikkan sintaksis ekspresi baru.
Langkah 5: Validasi URI akhir
Setelah ekspansi, gunakan parser URI standar untuk skema, otoritas, path, kueri, dan fragmen. Untuk permintaan sisi server, skema, host, dan port harus cocok dengan allowlist; resolusi DNS juga harus memblokir alamat loopback, link-local, dan privat, serta pengalihan (redirect) harus diperiksa kembali. Normalisasikan path sebelum memeriksa root yang diizinkan agar .. yang di-encode tidak dapat melewati aturan.
Langkah 6: Buat tautan API mudah dipelihara
Template paginasi harus menentukan variabel mana yang dibuat oleh server, sedangkan filter menggunakan nama dan tipe variabel yang tetap. Jangan memasukkan tanda tangan (signature), token akses, atau nama host internal ke dalam template atau hasil publik. Catat versi template, skema variabel, dan kesalahan ekspansi. Jika urutan yang stabil diperlukan, lapisan bisnis harus menyediakannya daripada mengandalkan urutan string parameter.
Langkah 7: Bangun pengujian dan pemantauan
Uji setiap operator dengan nilai tunggal, daftar, peta, nilai kosong, dan nilai yang tidak terdefinisi terhadap contoh spesifikasi. Tambahkan karakter khusus, Unicode, kunci kueri berulang, prefiks panjang, double encoding, %2e%2e, skema alternatif, redirect, dan kasus resolusi DNS. Pantau kegagalan ekspansi, alasan penolakan, distribusi origin tujuan, dan panjang yang tidak normal, serta picu peninjauan saat konfigurasi template berubah.
Contoh jawaban berkualitas tinggi
Pertama-tama saya akan membatasi operator RFC 6570 yang didukung dan memisahkan AST template, skema variabel, percent-encoding, dan validasi URI akhir. Daftar, peta, explode, dan prefiks mengikuti aturan masing-masing, dan variabel yang tidak terdefinisi diabaikan; nilai tidak dapat diurai ulang sebagai ekspresi. Setiap hasil tetap menjadi URI yang tidak tepercaya: urai hasilnya, izinkan hanya skema, host, port, dan path API yang dinormalisasi, blokir alamat privat untuk permintaan sisi server, dan periksa kembali setiap redirect. Pengujian mencakup contoh RFC, Unicode, nilai kosong, kunci berulang, double encoding, traversal, dan SSRF, dengan versi template dan alasan penolakan yang dicatat.
Kesalahan umum
- Mengganti semantik operator dengan penggabungan string sehingga merusak pemisah atau percent-encoding.
- Memperlakukan ekspansi reserved
+sebagai "tanpa encoding sama sekali" dan mengabaikan batas komponen. - Memperlakukan daftar, peta, dan explode sebagai satu format penggabungan koma.
- Hanya memvalidasi teks template alih-alih skema, host, port, dan path yang dinormalisasi setelah diekspansi.
- Memperlakukan URL encoding sebagai perlindungan SSRF dan mengikuti redirect tanpa validasi ulang.
Pertanyaan lanjutan dan tanggapan
Lanjutan 1: Apa yang harus terjadi pada variabel yang tidak terdefinisi?
Abaikan variabel yang tidak terdefinisi dan pemisah yang diperlukan sesuai dengan ekspresi. Jangan me-render string null. Jika skema bisnis mewajibkan variabel tersebut, tolak sebelum ekspansi.
Lanjutan 2: Mengapa tidak memanggil satu fungsi URL-encode saja?
Encoding bergantung pada ekspresi dan komponen URI. Parameter kueri, segmen path, dan ekspansi reserved memiliki pemisah dan aturan yang berbeda. Satu fungsi tidak dapat memutuskan nilai komposit, nilai kosong, prefiks, dan operator.
Lanjutan 3: Bagaimana Anda mengurangi risiko untuk template tenant?
Gunakan subset operator yang ditinjau, skema variabel yang tetap, dan komponen output yang tetap. Larang skema atau otoritas sembarangan, lalu tetap terapkan allowlist origin, normalisasi path, pemeriksaan DNS/IP, dan validasi ulang redirect setelah ekspansi.
Lanjutan 4: Bisakah pengubah prefiks memotong rahasia (secret)?
Itu adalah semantik prefiks string URI Template, bukan masking privasi atau pemotongan aman Unicode. Mask data sensitif pada lapisan bisnis, di mana panjang dan batasan karakter merupakan kebijakan yang eksplisit.
Lanjutan 5: Bagaimana Anda membuktikan kompatibilitas RFC 6570?
Jalankan contoh spesifikasi RFC 6570 dan pengujian tingkat operator, bandingkan ekspansi yang diharapkan untuk setiap tipe variabel, lalu tambahkan kasus penolakan khusus proyek dan dokumentasikan tingkatan yang tidak didukung serta perbedaannya.