Saya Melakukan Tiga Kesilapan Auth yang Mahal dengan Next.js 16
Saya telah merosakkan matcher proxy.ts pada tiga projek yang berbeza.
Bahagian yang paling teruk? Tiada ralat. Tiada amaran. Tiada log. Semuanya kelihatan sempurna sehinggalah lubang keselamatan muncul.
Next.js 16 telah menukar middleware.ts kepada proxy.ts. Ini bukan sekadar pertukaran nama. Ia adalah peralihan asas dalam cara anda mengendalikan permintaan.
Berikut adalah apa yang anda perlu tahu untuk mengelakkan sistem auth anda rosak.
Peraturan Baharu Middleware sebelum ini mengelirukan. Pembangun menggunakannya untuk panggilan pangkalan data dan logik yang berat. Itu bukan tugasnya.
Proxy terletak pada sempadan rangkaian. Ia memintas permintaan sebelum ia sampai ke laluan anda.
- Ia berjalan pada Node.js secara lalai, bukan runtime Edge.
- Anda mendapat sokongan kripto penuh.
- Anda boleh menggunakan sebarang perpustakaan JWT standard tanpa jalan pintas.
Kegagalan Senyap
Jika anda menaik taraf Next.js tanpa menggunakan codemod, fail middleware.ts lama anda mungkin kekal dalam projek anda. Ia akan melepasi semakan TypeScript. Ia akan dikompil dengan baik.
Tetapi ia tidak akan melakukan apa-apa.
Pengalihan (redirects) anda tidak akan berfungsi. Auth anda tidak akan berjalan. Aplikasi anda hanya akan memintas lapisan keselamatan secara senyap.
Semak Tiga Perkara Ini Secara Manual:
- Pastikan
proxy.tsberada di akar (root) projek anda. - Pastikan fungsi yang dieksport dinamakan
proxy, bukanmiddleware. - Padam fail
middleware.tslama sepenuhnya.
Perangkap Matcher Kebanyakan tetapan auth rosak pada konfigurasi matcher. Jika anda tidak mengecualikan fail statik, proxy akan berjalan pada setiap fail CSS dan JS. Ini mewujudkan gelung pengalihan (redirect loops) tanpa henti pada aset.
Gunakan negative lookahead untuk mengecualikan:
_next/static_next/image- favicons dan sitemaps
- sambungan imej (png, jpg, svg)
Amaran: Jangan Percaya Header Sahaja Di sinilah saya terkena.
Proxy menetapkan header seperti x-user-id pada permintaan. Server Components anda membaca ini melalui headers().
Jika matcher anda mempunyai jurang, pengguna boleh menghantar header x-user-id mereka sendiri. Server Component tidak dapat membezakan antara header yang ditetapkan oleh proxy dengan header yang dihantar oleh klien.
Penyerang boleh memalsukan (spoof) ID pengguna pada laluan yang tidak sepadan. Mereka mungkin tidak dapat melihat data, tetapi mereka boleh memperoleh keizinan yang sepatutnya tidak mereka miliki.
Penyelesaian: Proxy adalah pintu gerbang pantas anda. Ia mengendalikan kerja berat di edge.
Tetapi anda mesti mengesahkan JWT sekali lagi di dalam Server Components anda.
- Proksi menyekat kebanyakan pelaku jahat dengan cepat.
- Semakan Komponen Pelayan menutup jurang jika pemadan gagal.
Redundansi adalah keselamatan.