Empat Kontrak di Balik Formulir Unggah Publik

Adityo Guni Waluyo13 Oktober 202604.35

Formulir multipart publik menegakkan empat kontrak sekaligus: enum tertutup, slot berkas kondisional, batas unggah, dan migrasi skema.

#go #multipart #file-upload #mysql #migration

Ringkasan

Gawatnya, form upload publik frm02 ternyata punya empat kontrak tersembunyi yang harus sinkron: enum di level aplikasi, file wajib cuma kalau syaratnya true, upload dipagin 10 MiB plus cek magic byte, dan migrasi ENUM yang aman saat rollback. Salah satu lapisan geser dikit, validasi langsung ribut. Intinya: jangan ubah satu kontrak sendirian.

Empat Kontrak Tersembunyi di Balik Formulir Unggah Publik

Terminal menampilkan log error validasi yang tidak konsisten saat mengintegrasikan formulir publik baru. Data yang dikirim lolos di sisi klien, tetapi ditolak oleh server dengan pesan yang membingungkan. Dugaan awal mengarah pada batas ukuran file yang terlalu ketat di level reverse proxy atau konfigurasi CORS yang salah.

Pemeriksaan log reverse proxy menunjukkan payload berhasil masuk utuh. Asumsi bahwa server memotong permintaan ternyata keliru. Permintaan mencapai aplikasi, namun status akhirnya gagal diverifikasi pada lapisan bisnis.

Analisis lebih dalam mengungkapkan fakta bahwa satu titik akhir formulir multipart publik sebenarnya menegakkan empat kontrak terpisah. Keempat lapisan ini harus tetap sinkron. Proses frm02 validasi upload migrasi ini menuntut ketelitian pada empat lapisan berbeda. Kegagalan terjadi ketika salah satu kontrak tidak selaras dengan perubahan di kontrak lainnya.

Enum Tertutup di Tingkat Aplikasi

Kontrak pertama mengatur validasi nilai field teks. Alih-alih mengandalkan enumerasi basis data, sistem menerapkan closed-set field enums yang diturunkan secara manual dalam bahasa Go. Pendekatan ini menggunakan slice allowlists untuk memvalidasi input sebelum diproses lebih lanjut.

Referensi implementasi parser multipart ada di paket net/http Go [1].

Keputusan ini menghindari ketergantungan pada skema basis data untuk logika bisnis tingkat aplikasi. Hal tersebut memberikan fleksibilitas saat struktur tabel berubah tanpa mengharuskan perubahan kode validasi yang kompleks. Validasi di tingkat aplikasi juga terjadi lebih cepat, mengurangi beban kueri ke basis data untuk setiap permintaan yang masuk.

Persyaratan File Bersyarat

Kontrak kedua menangani logika ketergantungan antar field. Slot unggahan file tidak selalu wajib. Sebagai contoh, slot izin_keramaian hanya menjadi persyaratan wajib ketika nilai field ButuhIzinKeramaian bernilai true.

Validasi ini memastikan klien tidak dapat mengabaikan dokumen penting saat konteks formulir mengharuskannya. Di saat yang sama, sistem tidak membebani pengguna dengan unggahan yang tidak relevan pada skenario lain. Logika ini mencegah penolakan yang salah akibat validasi kaku yang mengabaikan konteks bisnis formulir.

Jalur Tulis Streaming dengan Batas Ketat

Kontrak ketiga melindungi infrastruktur dari penyalahgunaan sumber daya. Proses ini memanfaatkan perilaku ParseMultipartForm dalam paket net/http yang mengatur batas maxMemory sebelum melimpahkan data sementara ke disk. Jika batas ini tidak dikelola, serangan denial-of-service dapat dengan mudah memenuhi penyimpanan disk server.

Untuk mencegah penyalahgunaan, setiap file dibatasi secara ketat menggunakan io.LimitReader dengan batas maksimum 10 MiB ditambah satu byte. OWASP menyarankan menyimpan berkas di luar webroot yang hanya bisa diakses administratif [2]. Sebelum file disimpan, sistem melakukan magic-byte sniffing untuk memverifikasi tipe file sebenarnya, bukan hanya mengandalkan ekstensi yang dikirim klien yang dapat dengan mudah dipalsukan.

File yang lolos validasi kemudian disimpan ke penyimpanan privat di luar direktori webroot. Nama file diacak secara kriptografis untuk mencegah akses langsung melalui tebakan URL.

Migrasi Skema dan Kontrol Akses

Kontrak keempat menjamin evolusi skema basis data tetap aman. Migrasi 000073 dirancang untuk memperluas kolom ENUM seperti jenis atau submission_type; ENUM sendiri adalah tipe string yang nilai-nilainya didaftarkan eksplisit saat pembuatan tabel [4]. Ketika rollback diperlukan, sistem tidak langsung mempersempit kolom ENUM karena akan menyebabkan error jika data lama masih ada.

Sebaliknya, migrasi turun membersihkan data yang tidak sesuai terlebih dahulu sebelum mempersempit definisi kolom, mengikuti pola tool migrasi yang menerapkan berkas migrasi secara berurutan [5]. Proses pembersihan data ini biasanya melibatkan pembaruan nilai ENUM yang tidak lagi valid menjadi nilai default atau null, memastikan skema baru dapat diterapkan tanpa konflik. Tanpa sinkronisasi yang tepat, implementasi frm02 validasi upload migrasi akan menghasilkan inkonsistensi data yang sulit dilacak dan berpotensi merusak integritas tabel.

Selain itu, kontrol akses berbasis peran diterapkan melalui pemetaan rekomendasiScope. Akses satu bidang dibatasi pada kode tertentu, sedangkan akses lintas bidang memerlukan izin ALL. Pemetaan ini memastikan bahwa pengguna dengan peran terbatas hanya dapat melihat atau memodifikasi data yang berada dalam lingkup bidang mereka. Pemahaman mendalam tentang mekanisme frm02 validasi upload migrasi mencegah kegagalan sistem di lingkungan produksi.