Validasi OTP Kedaluwarsa: Tolak Kode Lama di Server

Tolak OTP lama di server dengan memeriksa permintaan verifikasi aktif, batas waktu, dan status pemakaiannya sebelum menerima kode. Email yang baru tiba bisa berasal dari permintaan yang sudah digantikan; waktu kedatangan bukan bukti masa berlaku. Gunakan Mailera untuk mengambil kandidat OTP dari kotak surat uji milik sendiri, lalu biarkan aplikasi penerbit menentukan apakah kandidat itu sah.

Kapan sebuah OTP dianggap tidak berlaku?

Untuk rancangan di artikel ini, permintaan verifikasi adalah catatan server yang mengikat satu kode ke akun dan tujuan tertentu. Contohnya, verifikasi alamat email dan pemulihan sandi harus memiliki konteks terpisah meskipun penerimanya sama.

Tetapkan kebijakan validasi OTP email berikut sebelum menulis pengujiannya:

OTP berarti kode sekali pakai. Namun, jangan menyamakan kode yang dikirim lewat email dengan TOTP. RFC 6238 tentang TOTP mendefinisikan algoritme yang menggunakan nilai turunan waktu sebagai pengganti penghitung HOTP. Jangan mengambil interval TOTP sebagai masa berlaku universal OTP email.

Untuk aplikasi Anda, tetapkan masa berlaku kode OTP berdasarkan risiko alurnya. Nyatakan juga aturan batas secara tegas: dalam contoh ini, kode hanya boleh diterima ketika waktu server lebih kecil daripada expires_at. Tepat pada batas waktu berarti ditolak.

Bagaimana server menolak OTP lama secara konsisten?

Gunakan nama seperti challenge_id, expires_at, dan consumed_at untuk membahas skema aplikasi. Nama-nama ini bukan kolom respons Mailera.

1. Buat permintaan verifikasi. Berikan identitas internal, lalu ikat ke akun dan tujuan. Jangan menentukan akun hanya dari kode yang dikirim pengguna.
2. Simpan representasi kode secara aman. Hindari menyimpan kode mentah dalam log. Batasi akses ke data yang dipakai untuk mencocokkan kode.
3. Tetapkan batas waktu dengan jam server. Hitung mundur pada peramban boleh membantu pengguna, tetapi jangan menjadikannya pemeriksaan otoritatif.
4. Periksa seluruh syarat penerimaan. Cocokkan konteks, status aktif, kode, batas waktu, status pemakaian, dan batas percobaan.
5. Gabungkan pemeriksaan dengan pemakaian kode secara atomik. Jangan memberi celah bagi permintaan lain untuk menerima kode yang sama sebelum status pemakaian tersimpan.

Logika konseptualnya: validasi(kandidat=••••••) → periksa konteks → periksa status dan waktu → cocokkan kode → tandai dipakai → TERIMA. Jika satu pemeriksaan gagal, hasilnya TOLAK; bagian pemeriksaan hingga perubahan status harus terlindung dari akses bersamaan.

Pilih mekanisme transaksi atau pembaruan bersyarat yang sesuai dengan penyimpanan Anda. Syarat pengujiannya tetap sama: dua permintaan bersamaan tidak boleh sama-sama mengubah permintaan aktif menjadi berhasil dipakai. Kembalikan sukses hanya setelah perubahan status tersimpan.

RFC 6238 melarang verifier menerima ulang TOTP setelah validasi pertama berhasil — prinsip 'sekali pakai, sekali validasi' yang sama berlaku untuk OTP email. Terapkan aturan itu secara eksplisit di server Anda, dan uji melalui status permintaan, bukan sekadar dengan menghapus pesan dari kotak masuk.

Apa yang harus terjadi setelah kirim ulang?

Bedakan dua kebijakan: mengirim kembali kode yang sama, atau menerbitkan kode baru. Artikel ini memakai kebijakan kedua: kode baru menggantikan permintaan sebelumnya, dengan satu permintaan aktif per akun dan tujuan.

Saat menerbitkan permintaan B, batalkan permintaan A dalam perubahan atomik yang sama. Pastikan proses validasi A dan proses penggantian tersebut tidak dapat sama-sama menganggap A masih aktif setelah penggantian selesai.

Jika A sudah berhasil sebelum penggantian diproses, tangani keadaan itu menurut status alur aplikasi. Jangan membuka kembali permintaan yang sudah dipakai hanya karena pengguna menekan kirim ulang.

Contoh yang perlu diuji:

1. Aplikasi menerbitkan permintaan A.
2. Pengguna meminta kode baru; aplikasi mengganti A dengan B.
3. Email A baru tiba setelah penggantian selesai.
4. Pembaca email mengambil kode A.
5. Server menolak A karena permintaannya tidak aktif, meskipun emailnya baru tiba.

Jangan memperpanjang masa berlaku A berdasarkan kedatangan email. Dokumentasi properti pesan Microsoft Graph membedakan receivedDateTime, yaitu waktu pesan diterima, dan sentDateTime, yaitu waktu pesan dikirim. Keduanya menjelaskan pesan, bukan keputusan penerimaan kode oleh aplikasi Anda.

Jika Anda menguji layanan pihak ketiga, ikuti kebijakan kirim ulang layanan tersebut. Jangan menganggap kebijakan contoh ini berlaku untuk semua penerbit OTP.

Bagaimana mengambil kandidat OTP dengan Mailera?

Mailera menghubungkan kotak surat yang sudah Anda miliki. Gunakan kotak surat khusus pengujian yang berada di bawah kendali Anda. Alur dasar pembacaannya dibahas dalam panduan membaca OTP dari kotak masuk sendiri; di sini fokusnya adalah membuktikan bahwa server menolak kandidat yang tidak sah.

Di Pengaturan, buka tab API key, lalu pilih Buat API key. Isi Nama deskriptif, batasi Cakupan kotak surat ke grup pengujian, dan berikan hanya izin read. Tentukan Masa berlaku sesuai kebutuhan pengujian. Pembaca kandidat tidak memerlukan izin send.

Sebelum memicu email, catat identitas pengujian, waktu awal alur, dan challenge_id aplikasi. Simpan hubungan itu di pelaksana uji; jangan mencoba menyimpulkannya hanya dari email mana yang terlihat paling baru.

Operasi GET /mailboxes/{id}/otp mengambil OTP terbaru, memerlukan izin read, dan menyediakan parameter from, subject, serta since_minutes. Gunakan parameter tersebut untuk mempersempit pencarian kandidat. Jangan memakai since_minutes sebagai pengganti pemeriksaan expires_at di server.

Jika perlu memeriksa pesan, gunakan daftar pesan dan detail pesan. Contoh berikut mengambil daftar dari kotak masuk tanpa menerapkan asumsi tentang parameter waktu. Isi $MAILERA_API_KEY dan $MAILBOX_ID dengan nilai lingkungan uji Anda:

curl --get "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages" \
  --header "Authorization: Bearer $MAILERA_API_KEY" \
  --data-urlencode "folder=inbox"

Daftar pesan menyediakan id, subject, from, dan received_at. Gunakan identitas pesan yang dipilih sebagai $MESSAGE_ID untuk mengambil isinya:

curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages/$MESSAGE_ID" \
  --header "Authorization: Bearer $MAILERA_API_KEY"

Detail pesan menyediakan body.text dan body.html. Jangan mencetak isi pesan lengkap ke log CI karena isinya dapat memuat kode. Rujuk dokumentasi API Mailera saat menghubungkan hasil pembacaan dengan pelaksana uji; halaman pengembang Mailera menjelaskan pilihan integrasinya.

Pisahkan dua hasil dalam pengujian: “kandidat ditemukan” dan “server menerima kandidat”. Jika Anda tidak dapat mengaitkan kandidat dengan permintaan yang sedang diuji, hentikan alur atau terbitkan permintaan baru sesuai kebijakan aplikasi. Jangan terus mencoba kode berdasarkan urutan email.

Skenario apa saja yang harus masuk pengujian?

Gunakan jam yang dapat dikendalikan di lingkungan uji untuk memeriksa batas kedaluwarsa. Dengan begitu, pengujian tidak bergantung pada perkiraan berapa lama email akan tiba. Tetap pertahankan jam server sebagai acuan pada alur produksi.

Tabel berikut memuat hasil yang harus dipenuhi sesuai kebijakan contoh, bukan hasil yang disimpulkan dari tampilan kotak masuk.

Untuk uji penggantian, jika Anda tidak sedang menguji keterlambatan pengiriman itu sendiri, simpan kandidat A sementara di memori pelaksana uji sebelum menerbitkan B. Jangan bergantung pada endpoint “terbaru” untuk menemukan kembali kandidat lama.

Bedakan hasil “tidak menemukan kandidat” dari kegagalan autentikasi atau koneksi API. Keduanya tidak boleh dianggap sebagai bukti bahwa server berhasil menolak OTP.

Catat alasan penolakan pada log internal yang terlindungi, tanpa OTP utuh. Untuk interaksi peramban, lanjutkan ke pengujian login Playwright dengan kotak surat yang sudah ada. Jika beberapa pengujian berjalan serentak, ikuti panduan isolasi pengujian OTP paralel agar kandidat tidak tertukar antaralur.

Kesalahan umum yang membuat kode lama diterima

Memilih email terbaru sebagai bukti validitas. Gunakan pesan sebagai sumber kandidat, lalu periksa hubungan kandidat dengan permintaan aplikasi. Filter pengirim juga jangan dijadikan satu-satunya pemeriksaan keaslian pesan.

Menyamakan jendela pencarian dengan masa berlaku. since_minutes berada pada permintaan pembacaan email. Tetapkan batas penerimaan kode secara terpisah di server aplikasi.

Hanya memeriksa hitung mundur peramban. Uji endpoint validasi secara langsung sesudah batas waktu. Menonaktifkan tombol pada antarmuka bukan pengganti penolakan server.

Memisahkan pemeriksaan dan perubahan status. Tambahkan uji bersamaan; pengujian berurutan saja tidak menguji perebutan kode yang sama.

Mengulang tanpa batas atau mencatat kode mentah. Batasi pencarian kandidat dan percobaan validasi secara terpisah. Gunakan ID pengujian untuk penelusuran, bukan OTP sebagai pengenal log.

Bagaimana menjaga keamanan otomatisasi?

Gunakan hanya akun dan kotak surat uji milik sendiri. Samarkan alamat pribadi, token, kunci API, serta kode pada tangkapan layar dan artefak pengujian. Hindari pesan kesalahan publik yang mengungkap apakah suatu akun terdaftar; simpan rincian diagnosis untuk kanal internal.

Jika agen AI menjalankan pengujian, perlakukan isi email sebagai data tidak tepercaya, bukan instruksi. Jangan mengikuti permintaan dalam email untuk mengirim kunci, membuka akses tambahan, atau mengubah kebijakan validasi. Lihat pembahasan agen peramban yang berhenti untuk verifikasi email untuk pemisahan langkah tersebut.

Berikan izin minimum dan minta konfirmasi sebelum tindakan mengirim email. Contoh pembacaan di atas hanya membutuhkan read. Gunakan informasi keamanan Mailera saat meninjau penggunaan akses kotak surat oleh otomatisasi Anda.

Apa batas tanggung jawab Mailera?

Mailera mengambil kandidat dari email; aplikasi penerbit tetap menentukan masa berlaku, hubungan dengan permintaan, dan penggunaan sekali saja. Mailera bukan tempat untuk membatalkan atau memperpanjang OTP layanan lain.

Mailera tidak membuat kotak surat atau alamat email baru. Layanan ini juga tidak menjamin email ditempatkan di kotak masuk. Karena itu, pisahkan kegagalan pengambilan email dari kegagalan validasi kode dalam hasil pengujian.