Mata Kuliah Lab Pemrograman • Bisnis Digital

Halaman Login Interaktif

Pertemuan 6 — Validasi dan Pengamanan Dasar

Setelah menguasai state dan props pekan lalu, hari ini kita pakai keduanya untuk kasus paling sering ditemui pada aplikasi bisnis digital: halaman login — lengkap dengan aturan validasi dan langkah pengamanan dasar.

RPS MINGGU 6 • 2X50 MENIT

Selamat datang di pertemuan keenam, Anda sekarang sudah punya modal state dan props dari minggu lalu — dua konsep yang hari ini akan langsung Anda praktikkan pada kasus nyata: halaman login. Hampir semua aplikasi bisnis digital yang Anda pakai sehari-hari, mulai dari BCA mobile, Tokopedia, sampai Gojek, mewajibkan pengguna login sebelum bertransaksi, dan di balik layar sederhana itu ada logika validasi serta pengamanan yang cukup rumit. Hari ini Anda akan membangun sendiri kolom email dan kata sandi yang "mengingat" ketikan pengguna lewat state, memvalidasi formatnya sebelum tombol masuk aktif, dan menerapkan langkah pengamanan dasar seperti menyembunyikan karakter kata sandi. Siapkan laptop dan Expo Go Anda, karena kita akan langsung membangun komponen ini bersama-sama sepanjang dua sesi hari ini.

Tujuan Pembelajaran Hari Ini

Melanjutkan konsep state dan props dari Pertemuan 5, hari ini Anda membangun halaman login yang fungsional dan aman:

CAPAIAN 1 — VALIDASI

MEMVALIDASI INPUT

Menerapkan aturan validasi format email dan panjang kata sandi sebelum data dikirim ke server.

CAPAIAN 2 — PENGAMANAN

MENGAMANKAN DATA

Menerapkan langkah pengamanan dasar: penyembunyian kata sandi, larangan simpan teks polos, dan koneksi terenkripsi.

Sub-CPMK Minggu 6: mahasiswa mampu mengembangkan halaman login interaktif dengan validasi dan pengamanan dasar menggunakan React Native.

Bagian 1 dari 3

Membangun Formulir Login dengan State

Setiap ketikan pengguna di kolom email dan kata sandi perlu "diingat" komponen — di sinilah state kembali berperan.

Analogi: Formulir Kertas vs Formulir Digital Terpantau

FORMULIR KERTAS

TIDAK TERPANTAU

Petugas hanya membaca isian saat formulir diserahkan di akhir. Sistem tidak tahu apa yang sedang Anda tulis selagi Anda menulis.

FORMULIR DIGITAL LOGIN

TERPANTAU REAL-TIME

Setiap huruf yang diketik langsung tersimpan di state, sehingga aplikasi bisa langsung memvalidasi — misalnya memberi tanda merah begitu format email salah.

Glosarium — komponen terkontrol (controlled component): komponen input yang nilainya sepenuhnya diatur oleh state React Native, bukan disimpan sendiri oleh komponen input tersebut.

Membuat State untuk Email & Kata Sandi

Dua kolom login butuh dua state terpisah, masing-masing dibuat dengan useState:

// State untuk menyimpan ketikan pengguna
const [email, setEmail] = useState('');
const [sandi, setSandi] = useState('');

email / setEmail

Menyimpan teks yang diketik di kolom email, nilai awal string kosong ''.

sandi / setSandi

Menyimpan teks yang diketik di kolom kata sandi, nilai awal string kosong ''.

Menghubungkan State ke TextInput

<TextInput
  placeholder="Email"
  value={email}
  onChangeText={(teks) => setEmail(teks)}
/>
<TextInput
  placeholder="Kata Sandi"
  value={sandi}
  onChangeText={(teks) => setSandi(teks)}
  secureTextEntry={true}
/>

Glosarium — secureTextEntry: properti bawaan TextInput yang menyembunyikan karakter yang diketik pengguna, ditampilkan sebagai titik atau bintang — langkah pengamanan paling dasar pada kolom kata sandi.

Hitung dari Nol: Melacak Panjang Kata Sandi

Syarat minimal kata sandi adalah 8 karakter. Mari lacak nilai sandi.length saat pengguna mengetik bertahap.

Langkah	Perhitungan	Panjang sandi
Ketik "sandi"	s-a-n-d-i = 5 karakter	5
Tambah "123"	5 + 3 karakter	8
Uji syarat minimal	8 ≥ 8	valid = true
Tambah simbol "!"	8 + 1 karakter	9

HASIL AKHIR

9 ≥ 8

"sandi123!" memenuhi syarat panjang minimal — tombol masuk boleh aktif

Walkthrough: Tombol Masuk Aktif atau Tidak

Tombol "Masuk" sebaiknya hanya bisa ditekan kalau semua syarat validasi terpenuhi — mencegah pengguna mengirim data yang jelas salah.

const formValid = email.includes('@') && sandi.length >= 8;
<Button title="Masuk" disabled={!formValid} onPress={handleLogin} />

KONDISI 1 — BELUM VALID

email = "budi" (tanpa "@"), sandi = "123" (3 karakter) → formValid = false → tombol nonaktif (abu-abu).

KONDISI 2 — VALID

email = "budi@toko.id", sandi = "sandi123" → formValid = true → tombol aktif dan bisa ditekan.

Bagian 2 dari 3

Validasi — Menyaring Input Sebelum Dikirim

Bukan sekadar mengaktifkan tombol, validasi juga memberi tahu pengguna dengan tepat apa yang perlu diperbaiki.

Aturan Validasi Formulir Login

VALIDASI EMAIL

Harus mengandung tanda "@" dan domain (mis. ".com", ".id") menggunakan pola regex sederhana.

VALIDASI KATA SANDI

Minimal 8 karakter, disarankan mengandung huruf besar, angka, dan simbol agar lebih sulit ditebak.

Glosarium — regex (regular expression): pola teks yang dipakai untuk mencocokkan format string tertentu, misalnya memastikan sebuah teks berbentuk alamat email yang sah.

Menulis Fungsi Validasi

// Pola regex sederhana untuk format email
const polaEmail = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

function validasiForm() {
  if (!polaEmail.test(email)) return "Format email tidak valid";
  if (sandi.length < 8) return "Kata sandi minimal 8 karakter";
  return ""; // kosong artinya tidak ada kesalahan
}

Fungsi ini dipanggil setiap kali pengguna menekan tombol "Masuk" atau setiap ketikan berubah, hasilnya disimpan di state pesanError.

Mari telusuri fungsi ini baris demi baris. Baris pertama mendefinisikan pola regex untuk email — jangan khawatir menghafal simbolnya, cukup pahami maksudnya: teks sebelum "at", tanda "at" itu sendiri, lalu teks setelahnya yang mengandung titik seperti ".com" atau ".id". Fungsi validasiForm memeriksa dua syarat berurutan menggunakan pernyataan if: kalau email tidak cocok pola, ia langsung mengembalikan pesan kesalahan dan berhenti di situ, tidak perlu memeriksa kata sandi lagi. Kalau email lolos tapi kata sandi kurang dari delapan karakter, pesan kesalahan yang berbeda dikembalikan. Kalau keduanya lolos, fungsi mengembalikan string kosong yang berarti tidak ada kesalahan — pola "kembalikan lebih awal" seperti ini sangat umum dipakai untuk validasi berlapis di aplikasi nyata seperti Traveloka atau Blibli.

Hitung dari Nol: Skor Kekuatan Kata Sandi

Kata sandi "Toko0102!" diuji dengan 4 kriteria kekuatan. Tiap kriteria terpenuhi bernilai 1 poin.

Kriteria	Pemeriksaan	Poin
Panjang minimal 8	9 karakter ≥ 8	1
Ada huruf besar	"T" pada "Toko"	1
Ada angka	"0102" terdeteksi	1
Ada simbol	"!" terdeteksi	1

SKOR TOTAL

4 dari 4

1 + 1 + 1 + 1 = 4 → kategori "Kata Sandi Kuat"

Coba Sendiri: Uji Kekuatan Kata Sandi Anda

Ketik beberapa kata sandi berbeda, lalu amati bagaimana skor kekuatan dan entropinya berubah.

Menampilkan Pesan Kesalahan secara Kondisional

const [pesanError, setPesanError] = useState('');

<TextInput value={email} onChangeText={...} />
{pesanError !== '' && (
<Text style={{color: 'red'}}>{pesanError}</Text>
)}

Glosarium — rendering kondisional: teknik menampilkan elemen JSX hanya jika suatu kondisi bernilai benar, memakai operator && — elemen di sisi kanan hanya muncul jika sisi kiri bernilai true.

Bagian 3 dari 3

Pengamanan Dasar Halaman Login

Validasi menjaga data masuk rapi, tapi pengamanan menjaga data pengguna tidak bocor.

Tiga Prinsip Pengamanan yang Wajib Diterapkan

1. SEMBUNYIKAN SANDI

secureTextEntry aktif di kolom kata sandi, mencegah "pengintipan bahu" (shoulder surfing) saat pengguna mengetik di tempat umum.

2. JANGAN SIMPAN TEKS POLOS

Kata sandi tidak pernah disimpan mentah di state jangka panjang atau database — server harus melakukan hashing sebelum menyimpannya.

3. KONEKSI TERENKRIPSI

Data login dikirim lewat HTTPS (bukan HTTP biasa) agar tidak bisa disadap saat melintasi jaringan.

Glosarium — hashing: proses mengubah kata sandi menjadi kode acak satu-arah yang tidak bisa dikembalikan ke teks aslinya, dilakukan di sisi server sebelum disimpan ke database.

Tiga prinsip ini adalah standar minimum industri, bukan sekadar teori kelas. Prinsip pertama sudah Anda praktikkan lewat secureTextEntry tadi. Prinsip kedua penting Anda pahami walau implementasinya ada di sisi server: kata sandi yang diketik pengguna di aplikasi Anda tidak boleh pernah disimpan apa adanya, sebab kalau server pernah dibobol, kata sandi asli pengguna langsung terekspos — sebagai gantinya, server melakukan hashing, yaitu mengubah kata sandi menjadi kode acak yang praktis mustahil dikembalikan ke bentuk aslinya. Prinsip ketiga soal HTTPS memastikan data yang mengalir dari ponsel pengguna ke server dienkripsi sepanjang perjalanan, sehingga tidak bisa disadap di jaringan WiFi publik seperti di kafe. Ketiga prinsip ini adalah alasan mengapa aplikasi perbankan sangat ketat soal detail teknis yang terlihat sepele ini.

Alur Data: Dari Ketikan hingga Server

Diagram ini merangkum seluruh perjalanan data login dari ketikan pengguna sampai jawaban dari server, jadi mari kita telusuri urutannya. Dimulai dari TextInput yang menyimpan ketikan ke state, data itu diperiksa oleh fungsi validasiForm, dan hanya jika lolos, tombol masuk menjadi aktif dan bisa ditekan pengguna. Setelah ditekan, data dikirim melalui koneksi HTTPS yang terenkripsi menuju server, bukan lewat HTTP biasa yang rentan disadap. Di sisi server, kata sandi yang diterima diubah lagi melalui proses hashing dan dicocokkan dengan hash yang tersimpan di database — bukan dibandingkan sebagai teks polos. Terakhir, server mengirim balik respons berhasil atau ditolak ke aplikasi. Alur inilah yang terjadi setiap kali Anda login ke aplikasi seperti Tokopedia atau OVO, walau kecepatannya membuat prosesnya terasa instan.

Kesalahan Umum Pemula pada Halaman Login

KESALAHAN 1

Lupa secureTextEntry pada kolom kata sandi, sehingga karakter tampil jelas dan bisa terbaca orang di sekitar pengguna.

KESALAHAN 2

Validasi hanya di aplikasi (client-side) tanpa validasi ulang di server — pengguna jahat bisa melewati aplikasi dan mengirim data langsung ke server.

Ingat: validasi di aplikasi mobile hanya untuk kenyamanan pengguna; validasi di server tetap wajib karena aplikasi bisa "dilewati" oleh pihak yang tahu cara mengaksesnya langsung.

Dua kesalahan ini sangat umum ditemukan pada proyek pemula, jadi mari kita bahas kenapa keduanya berbahaya. Kesalahan pertama membuat kata sandi pengguna terlihat jelas di layar, risiko sederhana namun nyata terutama saat pengguna login di tempat umum seperti warung kopi atau transportasi umum. Kesalahan kedua lebih halus tapi lebih serius: banyak mahasiswa mengira validasi di aplikasi sudah cukup, padahal aplikasi mobile hanyalah salah satu cara mengakses server, dan pihak yang paham teknis bisa saja mengirim data langsung ke alamat server tanpa melewati aplikasi sama sekali, melewati semua validasi yang Anda tulis di React Native. Karena itu, aturan emasnya: validasi di aplikasi untuk kenyamanan dan kecepatan umpan balik, validasi di server untuk keamanan yang sesungguhnya — keduanya wajib ada, bukan salah satu saja.

Latihan Praktik (30 Menit)

Bangun halaman Login untuk aplikasi UMKM proyek Anda dengan ketentuan berikut:

Instruksi

Buat state email dan sandi, hubungkan ke dua TextInput terkontrol.
Aktifkan secureTextEntry pada kolom kata sandi.
Tulis fungsi validasiForm(): email wajib mengandung "@", sandi minimal 8 karakter.
Tampilkan pesan error secara kondisional, dan tombol "Masuk" hanya aktif jika form valid.

Kerjakan berpasangan di Expo Go. Dosen akan berkeliling untuk memeriksa hasil dan menjawab pertanyaan.

Rangkuman Konsep Kunci

VALIDASI

SARING INPUT

Regex untuk format email, cek panjang untuk kata sandi, pesan error ditampilkan secara kondisional.

PENGAMANAN

LINDUNGI DATA

secureTextEntry, hashing di server, dan koneksi HTTPS — tiga lapis pertahanan dasar.

Validasi menjaga kualitas data yang masuk; pengamanan menjaga kerahasiaan data pengguna. Halaman login yang baik butuh keduanya sekaligus.

Penutup & Tugas Mandiri

Tugas Sebelum Pertemuan 7

Selesaikan halaman Login dari latihan praktik, unggah ke repository proyek masing-masing.
Tambahkan validasi tambahan: konfirmasi kata sandi (kolom kedua) harus sama persis dengan kolom pertama.
Baca ulang glosarium regex, hashing, dan HTTPS sebagai bekal diskusi navigasi Pertemuan 7.

Pertemuan 7 kita akan menyambungkan halaman login ini ke navigasi antarhalaman — setelah login berhasil, pengguna otomatis berpindah ke halaman beranda.