‫Jonas: Sekarang mari kita lanjutkan
‫menulis fungsi perlindungan middleware.
‫Jadi di kuliah terakhir, kita membaca
‫token dari header otorisasi
‫dan kemudian memeriksa apakah token itu benar-benar ada.
‫Jadi di sini.
‫Dan selanjutnya, kami memiliki langkah verifikasi untuk token.
‫Dan saya harap Anda ingat
‫bahwa dalam langkah ini, kami memverifikasi jika
‫seseorang memanipulasi data atau juga jika token telah kedaluwarsa.
‫Jadi kita sudah menggunakan, dari paket token web JSON, fungsi assign
‫function, dan
‫sekarang kita akan menggunakan fungsi verifikasi.
‫Jadi seperti sebelumnya, jwt. verifikasi, dan
‫kemudian di sana, seperti yang dapat Anda bayangkan, kami melewati
‫token sehingga algoritme dapat membaca muatan dan
‫kemudian ingat bahwa langkah ini juga membutuhkan rahasia.
‫Jadi pada dasarnya, untuk membuat tanda tangan tes.
‫Jadi rahasia itu adalah proses. lingkungan JWT_SECRET.
‫Ingat bahwa?
‫Sekarang, sebagai argumen
‫ketiga, fungsi ini sebenarnya membutuhkan fungsi panggilan balik.
‫Jadi panggilan balik ini
‫akan berjalan segera setelah verifikasi selesai.
‫Jadi Anda melihat bahwa
‫verifikasi di sini sebenarnya adalah fungsi asinkron.
‫Jadi itu akan memverifikasi token, dan setelah itu,
‫setelah selesai,
‫itu akan memanggil fungsi panggilan balik yang bisa kita tentukan.
‫Sekarang, kami telah bekerja dengan janji sepanjang waktu,
‫dan saya tidak benar-benar ingin mematahkan pola itu di sini.
‫Jadi, kita sebenarnya akan menjanjikan fungsi ini.
‫Jadi pada dasarnya, untuk membuatnya mengembalikan janji.
‫Dan dengan begitu, kita kemudian dapat menggunakan
‫async waiting seperti fungsi async lainnya yang telah kita gunakan.
‫Jadi untuk
‫melakukan itu, Node sebenarnya memiliki fungsi promisify bawaan.
‫Yang perlu kita lakukan untuk
‫menggunakannya adalah membutuhkan modul util bawaan.
‫Jadi mari kita lakukan itu tepat di atas, sebenarnya.
‫Sehingga akan membuat objek bernama util, require...
‫Baiklah, jadi itu singkatan dari utilitas.
‫Bukan itu yang saya inginkan.
‫Jadi itu singkatan dari utilitas.
‫Dan kemudian di sana, kita akan menggunakan metode promisify.
‫Tapi karena kita hanya akan menggunakan satu metode itu, sebenarnya
‫kita bisa melakukannya dengan lebih mudah.
‫Jadi alih-alih
‫melakukan ini, kita cukup merusak objek itu dan
‫mengambil janji langsung dari sana.
‫Jadi sekali lagi, ini hanya menggunakan destrukturisasi ES6.
‫Oke, jadi dan sekarang sangat mudah digunakan.
‫Yang harus kita lakukan hanyalah menelepon promisify.
‫Jadi janjikan, lalu berikan fungsi di sana.
‫Jadi sekarang, semua ini di sini adalah fungsi
‫yang perlu
‫kita panggil, yang kemudian akan mengembalikan janji.
‫Jadi di sini, kita sebenarnya memanggil fungsinya.
‫Dan ini kemudian akan mengembalikan
‫sebuah janji, jadi kita bisa menunggunya dan menyimpan hasilnya ke dalam sebuah variabel.
‫Sehingga nilai hasil dari promise tersebut
‫akan benar-benar menjadi data yang
‫di-decode, jadi payload yang di-decode dari web token JSON ini.
‫Jadi izinkan saya menyebutnya diterjemahkan di sini.
‫Baiklah.
‫Dan kita bisa menunggu karena kita sebenarnya sudah mengatakan
‫bahwa itu adalah fungsi asinkron.
‫Dan sekarang, hanya untuk melihat bahwa itu benar-benar
‫berfungsi, mari kita log data yang didekodekan ini ke konsol juga.
‫Dan sebenarnya, kita dapat menghapus konsol ini. keluar dari token.
‫Yang tidak kita butuhkan lagi.
‫Jadi mari kita coba mengirim permintaan ini lagi, dan ya,
‫tetapi kali ini sebenarnya mengaktifkan header otorisasi
‫ini sehingga kami mengirim token web JSON bersama dengan permintaan tersebut.
‫Jadi yang mengirimnya.
‫Dan sekarang, memang, kami mendapatkan akses ke data,
‫dan oleh karena itu, kami sekarang memiliki akses ke rute yang dilindungi.
‫Oke?
‫Tapi yang ingin saya lihat adalah objek yang didekodekan di sini.
‫Jadi ini di sini harus menjadi ID pengguna.
‫Jadi mari kita lihat lagi di Postman.
‫Jadi 62a42.
‫Jadi, memang, di mana kita memilikinya?
‫Mari kita lihat Kompas.
‫Dan memang, ID pengguna ini adalah 62a42 ini.
‫Dan itu berarti bahwa kita benar-benar memiliki
‫muatan yang benar di sini.
‫Jadi pada dasarnya, ID pengguna yang benar.
‫Kami kemudian juga memiliki stempel waktu
‫tanggal pembuatan dan tanggal kedaluwarsa token.
‫Jadi ini bekerja.
‫Tapi sekarang mari kita coba memanipulasi payload token
‫ini.
‫Jadi mari kita salin di sini lagi.
‫Tapi kemudian saya akan pergi ke debugger JWT.
‫Jadi sekali lagi, di jwt. saya
‫Jadi mari kita ambil ini.
‫Dan sekarang yang akan saya lakukan adalah mengubah beberapa data
‫di sini dan itu kemudian akan mengubah token yang disandikan di sini, yang
‫kemudian dapat saya lanjutkan dan salin.
‫Jadi mari kita ganti saja, sebenarnya,
‫saya hanya akan mengganti dua angka ini di sini
‫dengan sesuatu yang berbeda.
‫Jadi, seperti yang Anda lihat, ini mengubah token di sini.
‫Jadi sekarang, saya benar-benar akan mencoba mendapatkan
‫akses ke rute yang
‫dilindungi itu menggunakan token web JSON yang dimanipulasi ini.
‫Oke, masuk akal?
‫Jadi hanya untuk melihat apakah itu berfungsi dengan benar.
‫Jadi saya menyalin yang
‫ini di sini sekarang dan menempelkan yang lain ini.
‫Jadi, jika saya sekarang mengirim permintaan ini, maka kami mendapatkan kesalahan.
‫Sangat bagus.
‫Jadi, kami melihat nama kesalahannya adalah JsonWebTokenError, dan
‫kami memiliki tanda tangan yang tidak valid.
‫Sangat bagus.
‫Itulah yang kami cari.
‫Jadi itulah salah satu dari dua kesalahan yang bisa terjadi.
‫Yang lainnya adalah bahwa token telah kedaluwarsa.
‫Jadi yang ini disebut JsonWebTokenError, dan
‫sebenarnya, mari kita lanjutkan dan tangani kesalahan ini sekarang.
‫Dan cara yang
‫bisa kita lakukan adalah dengan menambahkan blok try-catch di sini.
‫Benar?
‫Jadi setelah melakukan kode ini, kita
‫bisa memperkenalkan blok try,
‫dan kemudian di catch, kita akan membuat kesalahan
‫yang akan dikirim ke klien.
‫Sekarang, alih-alih melakukannya seperti
‫itu, saya sebenarnya ingin menggunakan middleware penanganan kesalahan
‫global kami untuk melakukannya untuk kami.
‫Jadi kami tidak suka melakukan penanganan kesalahan di sini
‫di fungsi middleware kami.
‫Sebagai gantinya, kami biasanya mendelegasikannya ke pengontrol kesalahan.
‫Jadi, mari lakukan hal yang sama persis di sini.
‫Jadi pengontrol kesalahan.
‫Dan kemudian sebenarnya hal yang sama persis seperti
‫yang kita miliki dengan kesalahan kita yang lain di sini.
‫Jadi misalnya kesalahan validasi datang dari luwak, jadi
‫dari perpustakaan lain.
‫Dan sekarang, kesalahan ini sebenarnya berasal dari perpustakaan
‫lain dan juga memiliki namanya sendiri.
‫Jadi mari kita dapatkan itu.
‫Dan itu JsonWebTokenError.
‫Baiklah.
‫Jadi, mari kita lakukan yang sangat mirip di sini.
‫Jadi jika. namanya
‫ini, maka kesalahan harus sama dengan menangani kesalahan.
‫Oke.
‫Jadi mari kita
‫lanjutkan dan buat fungsi ini, sebenarnya, di suatu tempat di sini.
‫Dan yang satu ini sebenarnya sangat sederhana.
‫Yang dilakukannya hanyalah mengambil kesalahan dan
‫kemudian mengembalikan AppError baru.
‫Oke?
‫Jadi dalam
‫fungsi panah ES6 ini, seperti yang saya harap Anda ketahui, kita dapat menulis
‫satu baris ini di mana kita bahkan
‫tidak perlu menentukan kurung kurawal dan juga kata kunci return.
‫Jadi ini akan secara otomatis
‫dan implisit mengembalikan apa pun yang kita taruh di sini.
‫Benar?
‫Jadi,
‫yang ingin kami sampaikan di sini hanyalah, token tidak
‫valid, silakan masuk lagi.
‫Dan kemudian, kode kesalahan, seperti sebelumnya, adalah
‫401 untuk Tidak Diotorisasi.
‫Sekarang, ini hanya berfungsi, ingat, dalam produksi.
‫Jadi, jika kita melakukan ini sekarang lagi, maka kita
‫akan mendapatkan hal yang sama persis.
‫Jadi, mari kita kembali ke sini dan
‫menjalankan ini dalam produksi.
‫Jadi npm jalankan start:production.
‫Ya, begitu saja.
‫Jadi jika kita mencoba ini
‫sekarang lagi, mari kita lihat apakah kita mendapatkan kesalahan kita.
‫Dan memang, kami melakukannya.
‫Jadi jika, saat ini, pengguna dalam produksi
‫mencoba mengakses aplikasi kami dengan token
‫yang tidak valid, maka mereka hanya mendapatkan pesan kesalahan ini.
‫Baiklah?
‫Jadi itulah kesalahan pertama yang bisa kita dapatkan.
‫Tetapi satu lagi adalah bahwa pengguna mencoba
‫mengakses aplikasi dengan
‫token yang sudah kedaluwarsa.
‫Jadi, sekarang mari kita coba membuat kesalahan itu.
‫Dan untuk melakukan itu, saya
‫akan mengubah waktu yang dibutuhkan token untuk kedaluwarsa.
‫Jadi sekarang, kita punya 90 hari.
‫Mari kita lakukan, seperti, lima detik.
‫Oke.
‫Berikan simpanan.
‫Dan sekarang coba masuk lagi.
‫Jadi mari kita simpan yang ini di sini juga.
‫Jadi, di pengguna, lalu masuk.
‫Jadi kita bisa login, dan itu akan memberi kita token
‫baru, tapi token ini hanya berlaku selama lima detik.
‫Jadi, lima detik ini seharusnya sudah berlalu pada saat ini.
‫Jadi sekarang saya akan menyalin token ini dan mencoba mengakses
‫rute terlindungi kami menggunakan token itu.
‫Jadi tempel di sini.
‫Dan sekarang, mari kita lihat apa yang kita dapatkan.
‫Dan sebenarnya, untuk beberapa alasan, itu berhasil.
‫Jadi mari kita lihat debugger JWT kita lagi.
‫Dan dikatakan, dibuat tanggal 2 Mei, tetapi hanya kedaluwarsa
‫pada tanggal 31 Juli.
‫Jadi ada yang salah dalam pembuatan token itu, saya kira.
‫Jadi, mari kita ubah ini di sini lagi.
‫Dan aku hanya akan menempatkan lima di sini.
‫Jadi, lima itu kemudian harus
‫berdiri selama lima milidetik, atau saya bahkan bisa, seperti,
‫menempatkan 5000, yang kemudian menjadi lima detik.
‫Oke.
‫Jadi biarkan saya menyimpannya sekarang lagi untuk me-restart server.
‫Coba lagi.
‫Jadi login lagi di sini.
‫Baiklah.
‫Jadi sekarang yang
‫perlu kita lakukan pada dasarnya adalah menunggu lima detik, dan waktu itu seharusnya sudah berlalu pada saat ini.
‫Tempel di sini lagi.
‫Dan mari kita pergi.
‫Dan memang, kami mendapatkan kesalahan.
‫Sekarang ingat bagaimana ini pada
‫dasarnya adalah kesalahan standar yang kami dapatkan jika kami tidak
‫menangani kesalahan itu dengan benar dalam penanganan kesalahan kami.
‫Benar?
‫Jadi mari kita lihat kesalahannya.
‫Dan sebenarnya, kami memilikinya di sini di konsol.
‫Jadi mari kita lihat dari mana asalnya.
‫Dan ya, itu berasal dari tempat ini.
‫Jadi ini adalah kasus di mana kita memiliki kesalahan yang tidak diketahui.
‫Ingat, jadi kesalahan yang tidak ditandai sebagai kesalahan
‫operasional, dan karena itu kami
‫ingin mencatatnya.
‫Jadi kami mencatatnya di sini dan kemudian
‫kami mengirim pesan kesalahan umum
‫ini ke klien, jadi yang baru saja kami lihat
‫di Tukang Pos.
‫Tapi di sini kita sebenarnya rincian dari kesalahan ini.
‫Jadi, yang ini bernama TokenExpiredError.
‫Baiklah.
‫Jadi, sekarang mari kita tangani yang ini juga.
‫Jadi saya menyalinnya sekarang, dan kemudian membuat yang
‫lain jika di sini.
‫Jadi jika kesalahan. name sama dengan yang
‫ini, kalau
‫begitu, katakanlah, handleJWTExpiredError dengan panah.
‫Mari kita salin dan taruh di sini.
‫Dan ini, tentu saja, sangat mirip dengan yang sebelumnya.
‫Token Anda telah kedaluwarsa.
‫Silakan masuk lagi.
‫Dan lagi, dengan kode kesalahan 401.
‫Oke, mari kita coba lagi.
‫Jadi, itulah pesan kesalahan yang seharusnya
‫sekarang kita lihat di sini.
‫Baiklah.
‫Dan memang, itu.
‫Besar.
‫Mari selesaikan prosesnya di
‫sini dan mulai dalam mode dev, tentu saja.
‫Jadi npm
‫mulai, dan baiklah.
‫Jadi yang ini, kita tidak perlu lagi, jadi mari kita tutup.
‫Atau sebenarnya, mari kita perbaiki kesalahan kecil ini di sini, karena memang kami
‫tidak menggunakan kesalahan ini di sini sama sekali.
‫Jadi mari kita singkirkan itu.
‫Dan kemudian di bawah sini, kita tidak perlu melewatinya di sana.
‫Dingin.
‫Kami, tentu saja, juga perlu mengubah ini kembali ke 90 hari.
‫Baiklah.
‫Jadi,
‫untuk memastikannya, mari login lagi di sini,
‫salin tokennya,
‫dan taruh di sini.
‫Sekarang, proses menyalin token di sini dan
‫kemudian menempelkannya di sini di header ini mungkin
‫tampak agak aneh, dan sebenarnya kami akan memperbaikinya
‫di salah satu
‫video mendatang sehingga pada dasarnya,
‫proses ini terjadi secara otomatis.
‫Tapi sekarang, yang penting adalah itu benar-benar
‫kembali bekerja sekarang.
‫Jadi kita benar-benar bisa menyingkirkan konsol ini. login di sini dan lanjutkan
‫ke langkah berikutnya.
‫Dan kita benar-benar bisa berhenti di sini sekarang jika kita mau.
‫Dan lagi, sebagian besar tutorial yang akan
‫Anda temukan di sana, pada kenyataannya, akan berhenti di sini.
‫Tapi ini belum cukup aman.
‫Jadi misalnya, bagaimana jika pengguna
‫telah dihapus sementara itu?
‫Jadi tokennya akan tetap ada, tapi kalau
‫usernya sudah tidak ada, ya
‫kita sebenarnya tidak mau log in kan?
‫Atau lebih buruk lagi, bagaimana jika pengguna
‫benar-benar mengubah kata sandinya
‫setelah token dikeluarkan?
‫Yah, itu juga seharusnya tidak berhasil, bukan?
‫Misalnya, bayangkan seseorang
‫mencuri token web JSON dari pengguna.
‫Tapi kemudian,
‫untuk melindunginya, pengguna mengubah kata sandinya.
‫Jadi, tentu saja, token lama yang dikeluarkan
‫sebelum perubahan kata sandi seharusnya tidak berlaku lagi.
‫Jadi tidak boleh diterima untuk mengakses rute yang dilindungi.
‫Jadi, hal-hal seperti itulah yang akan kita terapkan
‫di langkah ketiga dan keempat.
‫Jadi hal pertama yang harus dilakukan adalah memeriksa apakah pengguna
‫benar-benar masih ada.
‫Jadi, yang itu harus yang paling mudah.
‫Jadi katakan saja, Pengguna. temukanById.
‫Jadi, inilah mengapa kami sebenarnya memiliki
‫ID di payload, karena
‫kami sekarang dapat menggunakan ID itu
‫dan meminta pengguna hanya menggunakan ID itu.
‫Jadi diterjemahkan. Indo.
‫Baiklah?
‫Jadi yang kemudian harus menemukan pengguna baru.
‫Dan tentu saja, kita perlu menunggu itu dan
‫kemudian menyimpannya ke dalam sebuah variabel.
‫Saya menyebutnya pengguna baru.
‫Baiklah?
‫Karena memang bukan pengguna baru.
‫Itu hanya ketika kita membuatnya.
‫Tapi ini sebenarnya bukan yang baru, ini benar-benar
‫hanya pengguna berdasarkan ID yang didekodekan.
‫Oke?
‫Dan hal
‫ini bisa kita lakukan agar bisa 100% yakin bahwa
‫ID tersebut benar-benar benar, karena jika
‫kita membuatnya sampai titik kode di sini maka itu berarti proses
‫verifikasi yang kita lakukan sebelumnya di sini berhasil.
‫Jika tidak, ini akan menyebabkan kesalahan
‫yang kemudian akan mencegah
‫fungsi melanjutkan.
‫Jadi, sekali lagi,
‫proses verifikasi ini bertugas memverifikasi jika tidak
‫ada yang mengubah ID yang
‫ada di payload token ini.
‫Jadi, karena itu, kami
‫dapat 100% yakin bahwa pengguna yang kami berikan
‫JWT adalah orang yang ID-nya sekarang berada di dalam
‫payload yang didekode, jadi yang ini.
‫Oke?
‫Jadi proses verifikasi sangat penting.
‫Ini benar-benar yang membuat semua ini berhasil.
‫Bagaimanapun, sekarang yang perlu kita lakukan adalah
‫memeriksa apakah memang ada freshUser.
‫Dan jika tidak, maka, tentu saja, kami
‫akan mengembalikan kesalahan baru.
‫Jadi jika tidak ada pengguna
‫baru, kembalilah dari middleware ini dan panggil
‫yang berikutnya dengan kesalahan.
‫Jadi ini adalah pola yang telah
‫kita lihat berulang kali pada saat ini, bukan?
‫Jadi tokennya sudah tidak
‫ada.
‫Dan sebenarnya, itu sebaliknya.
‫Jadi sebenarnya, pengguna
‫milik token sudah tidak ada lagi.
‫Benar?
‫Dan kemudian, 401.
‫Oke.
‫Jadi mari kita uji ini sekali lagi.
‫Dan mari kita buat pengguna baru untuk itu.
‫Jadi cukup uji dengan kata sandi yang sama jadi kami selalu menggunakan
‫kata sandi yang sama di sini hanya untuk
‫membuat pengujian kami sedikit lebih mudah.
‫Dan saya tahu bahwa semua pengujian di sini
‫membuat video memakan waktu yang sangat
‫lama, tetapi tentu saja, sangat penting bagi kami untuk menguji semua
‫yang kami lakukan,
‫terutama dalam topik penting seperti autentikasi.
‫Jadi saya sekarang menggunakan JWT ini di sini, jadi
‫saya menempelkannya di sini, tetapi tentu saja, sebelum mengirim permintaan, saya akan
‫melanjutkan dan menghapus pengguna itu segera.
‫Oke?
‫Jadi sekali lagi,
‫anggaplah seseorang membuat pengguna lalu masuk,
‫dan katakanlah, setelah beberapa waktu, pengguna tersebut dihapus.
‫Tetapi sementara itu, seseorang bisa mendapatkan akses ke
‫JWT
‫itu, dan sekarang dapat mencoba masuk sebagai
‫pengguna yang sebenarnya sudah dihapus.
‫Jadi, sekali lagi, kita tidak boleh membiarkan itu terjadi.
‫Jadi izinkan saya menghapus pengguna ini di sini sekarang.
‫Dan di sana kita pergi.
‫Jadi, mari kita uji sekarang.
‫Dan lagi, perlu diingat bahwa pengguna
‫milik ID yang ada di payload ini sekarang sudah tidak ada lagi.
‫Jadi mari kita lihat.
‫Dan memang, kami mendapatkan pesan kesalahan yang baru saja kami buat.
‫Jadi yang satu itu juga berfungsi.
‫Dan mari kita pergi ke yang terakhir.
‫Jadi langkah nomor empat, periksa apakah pengguna baru
‫saja mengubah kata sandi mereka.
‫Jadi pada dasarnya, setelah token dikeluarkan.
‫Dan untuk mengimplementasikan pengujian ini, kita sebenarnya akan membuat
‫metode instance lain.
‫Jadi pada dasarnya, metode
‫yang akan tersedia di semua dokumen.
‫Jadi dokumen adalah contoh dari model.
‫Baiklah?
‫Dan kami melakukan
‫ini karena cukup banyak kode yang kami butuhkan untuk verifikasi ini.
‫Jadi, sebenarnya, kode ini
‫milik model Pengguna dan bukan milik pengontrol.
‫Oke?
‫Jadi, mari kita
‫lakukan seperti yang kita lakukan sebelumnya untuk memeriksa kata sandi.
‫Jadi dalam model Pengguna, kami telah
‫mengimplementasikan metode contoh statis correctPassword ini, ingat?
‫Jadi, sekarang mari kita buat yang lain.
‫Jadi userSchema. metode. diubahPasswordAfter.
‫Jadi fungsi, dan ke dalam
‫fungsi ini, kita akan melewati cap waktu JWT.
‫Jadi pada dasarnya, stempel waktu yang
‫mengatakan kapan token dikeluarkan.
‫Jadi sebut saja JWTTimestamp.
‫Baiklah.
‫Dan secara default, kami akan mengembalikan false dari metode ini.
‫Dan itu berarti bahwa pengguna tidak
‫mengubah
‫kata sandinya setelah token dikeluarkan.
‫Oke?
‫Jadi mari kita taruh di sini, kembalikan false, pada dasarnya secara default.
‫Oke.
‫Tapi kemudian,
‫kami juga memiliki jika ini, dan ingat bahwa dalam metode instan, kata
‫kunci this selalu menunjuk ke dokumen saat ini.
‫Dan karena itu, di sini kita memiliki akses ke properti.
‫Sekarang, kita sebenarnya perlu membuat bidang sekarang dalam skema kita
‫untuk tanggal di mana kata sandi telah diubah.
‫Jadi kita belum punya itu.
‫Jadi mari kita cepat menambahkannya di sini.
‫Jadi passwordChangedAt, dan tipenya
‫adalah Date.
‫Sekarang, properti passwordChangedAt di sini akan
‫selalu berubah, tentu saja, ketika seseorang
‫mengubah kata sandi.
‫Jadi saat ini, kita tidak memiliki logika itu di mana pun,
‫dan tidak ada tempat kita benar-benar mendefinisikan properti ini.
‫Jadi, sebagian besar dokumen, jadi sebagian
‫besar pengguna, mereka tidak akan memiliki properti ini
‫di data mereka, jadi di objek mereka, bukan?
‫Jadi, tentu saja, kita perlu mengujinya.
‫Oke?
‫Jadi jika properti
‫passwordChangedAt ada, baru kita ingin benar-benar melakukan perbandingan.
‫Oke?
‫Tetapi jika
‫tidak, jadi jika passwordChanged tidak ada, maka itu berarti bahwa pengguna tidak
‫pernah benar-benar mengubah password, dan
‫oleh karena itu kita dapat mengembalikan false.
‫Jadi sekali lagi, itu default kami, artinya
‫pengguna tidak mengubah kata
‫sandi setelah stempel waktu ini.
‫Oke.
‫Dan
‫sekarang, untuk memulai, mari kita benar-benar masuk ke konsol ini. passwordChangedAt, dan tentu saja, JWTTimestamp juga, supaya kita
‫bisa
‫melihat bagaimana kita bisa membandingkannya.
‫Baiklah.
‫Dan sekarang kita
‫harus benar-benar membuat pengguna yang memiliki properti ini, oke?
‫Dan lagi, nanti di bagian saat kita akan menerapkan
‫logika untuk mengubah kata
‫sandi adalah saat kita akan menyetel properti ini.
‫Oke?
‫Tapi sekarang kita
‫akan secara artifisial, pada dasarnya, mengaturnya di sini ketika kita membuat pengguna baru.
‫Oke?
‫Jadi mari kita taruh di sini.
‫Dan di sini, tanggal berapa pun, sebenarnya, akan ditayangkan.
‫Jadi katakanlah 30 April 2019 di sini.
‫Dan itu kemudian harus diuraikan ke dalam MongoDB dengan baik.
‫Mari kita coba itu, lihat apakah itu berhasil.
‫Dan itu tidak berhasil.
‫Jadi itu tidak bisa benar-benar mengurai tanggal, katakanlah.
‫Dan sebenarnya, saya harus memulai dengan tahun
‫dan kemudian hari di akhir.
‫Jadi 2019 dan kemudian 30 April.
‫Coba itu lagi.
‫Dan Anda melihat bahwa sekarang ini benar-benar bekerja.
‫Jadi kami memiliki tanggal yang diuraikan di sini.
‫Oke?
‫Sekarang, untuk benar-benar melihat
‫hasil ini, tentu saja kita perlu memanggil metode ini.
‫Oke?
‫Jadi itulah yang akan kita lakukan di langkah keempat.
‫Oke?
‫Jadi, ingatlah
‫bahwa kita dapat memanggil metode instance ini pada dokumen pengguna.
‫Jadi pengguna segar. changePasswordAfter, dan kemudian cap
‫waktu itu.
‫Jadi itu di diterjemahkan. iat, jadi dikeluarkan pada, pada dasarnya.
‫Baiklah.
‫Jadi mari kita lihat saja hasil dari melakukan itu.
‫Jadi, tentu saja, ini seharusnya sekarang, bukan
‫di sini, jadi ini sekarang harus masuk ke konsol dua nilai ini.
‫Oke.
‫Sekarang, tentu
‫saja saya harus masuk dengan pengguna ini, jadi dengan tes,
‫jadi ini dia.
‫Gabung.
‫Salin token ini di sini lagi.
‫Dan lagi, pada dasarnya
‫kita akan mengotomatiskannya di video berikutnya.
‫Oke.
‫Tempelkan di sini.
‫Dan sekarang, kami benar-benar mendapatkan bug ini di sini.
‫Jadi saya hanya salah mengeja nama fungsi ini di sini.
‫Nah, mari kita salin saja.
‫Coba lagi.
‫Oh man.
‫Apa yang salah sekarang?
‫Dan sepertinya saya lupa log ini di sini.
‫Jadi kesalahan bodoh lainnya.
‫Mungkin melihat yang datang.
‫Tapi sekarang di sini kita pergi.
‫Jadi semuanya bekerja
‫dengan baik, dan yang benar-benar ingin
‫kami lihat saat ini adalah dua hasil ini.
‫Jadi pada dasarnya kita memiliki yang ini di
‫sini dalam format tanggal ini, dan kemudian yang lainnya dalam stempel waktu milidetik atau kedua
‫ini di sini.
‫Jadi, sekarang kita perlu mengonversi passwordChangedAt
‫ini juga menjadi stempel waktu seperti itu.
‫Baiklah?
‫Jadi, untuk itu, mari buat variabel baru.
‫Jadi berubah Timestamp.
‫Dan kita bisa menggunakan ini. kata sandiDiubahPada. dapatkanWaktu.
‫Oke?
‫Jadi, itulah
‫salah satu dari sekian banyak fungsi tanggal yang diberikan JavaScript kepada kita.
‫Baiklah.
‫Dan sekarang, mari kita
‫cepat membandingkan keduanya karena sebenarnya kita belum cukup siap.
‫Jadi mengirimkannya hanya untuk melihat hasilnya di sini.
‫Jadi apa yang kita lihat di sini pada dasarnya adalah
‫bahwa yang ini sekarang, pada
‫dasarnya, dalam hitungan detik, dan yang ini dalam milidetik.
‫Jadi 1000 kali lebih banyak.
‫Jadi, kita tahu kita perlu membaginya
‫dengan 1000 dan kemudian mengurai semuanya sebagai bilangan bulat.
‫Dan untuk itu, kami menggunakan parseInt.
‫Jadi fungsi JavaScript lain yang tersedia untuk angka.
‫Dan kemudian kita sebenarnya juga perlu menentukan dasarnya.
‫Jadi ini adalah bilangan basis 10.
‫Baiklah?
‫Dan sekarang, mari kita lihat lagi hasilnya.
‫Dan sekarang, itu terlihat jauh lebih ramah.
‫Oke.
‫Jadi, sekarang mari kita kembalikan hasil kita.
‫Dan sekali lagi, perlu diingat bahwa false berarti tidak berubah.
‫Oke?
‫Dan tidak
‫diubah pada dasarnya berarti bahwa hari atau waktu saat token dikeluarkan kurang
‫dari stempel waktu yang diubah.
‫Oke?
‫Jadi sebagai contoh
‫di sini, katakanlah token dikeluarkan pada waktu 100.
‫Tapi kemudian, kami mengubah kata sandi, katakanlah, pada waktu 200.
‫Oke?
‫Jadi, kami
‫mengubah kata sandi setelah token
‫dikeluarkan, dan oleh karena itu, ini sekarang benar.
‫Baiklah?
‫Dan itulah tepatnya yang ingin kami kembalikan
‫di sini, karena false berarti
‫tidak berubah, dan jadi true, tentu saja, berarti berubah.
‫Dan, itulah yang kita miliki di sini.
‫Tapi sekarang, katakanlah kata sandi terakhir
‫diubah pada
‫200, tetapi hanya setelah itu, kami
‫mengeluarkan token, jadi katakanlah, pada waktu 300.
‫Jadi, 300, kurang dari 200?
‫Tidak, itu salah.
‫Jadi, kami mengembalikan false, yang sekali lagi berarti tidak berubah.
‫Jadi, itulah mengapa kami menggunakan tanda less ini di sini.
‫Oke?
‫Mari kita kembali ke controller kita dan benar-benar menggunakan ini.
‫Jadi kalau passwordnya benar-benar diubah, nah, dalam hal
‫ini sebenarnya kita menginginkan sebuah kesalahan.
‫Jadi kembali berikutnya, sekali lagi, AppError baru.
‫Baru-baru ini...
‫Silakan masuk lagi.
‫Oke.
‫Dan sekali lagi, kode 401.
‫Baiklah.
‫Jadi sekali lagi,
‫ini akan mengembalikan true jika pengguna benar-benar mengubah kata sandinya.
‫Jadi, jika semua ini benar,
‫ya, maka dalam kasus itulah kita
‫ingin kesalahan ini terjadi.
‫Baiklah?
‫Jadi itu sebenarnya langkah terakhir.
‫Oke.
‫Jadi pada dasarnya, jika kode dapat membuat
‫semuanya sampai akhir kode ini di sini, baru kemudian, selanjutnya akan dieksekusi.
‫Dan kemudian, dengan berikutnya, kita pergi ke pengendali rute
‫berikutnya, yang secara efektif berarti memberikan akses ke
‫rute yang dilindungi itu.
‫Mari kita benar-benar menempatkan bahwa di sini.
‫Berikan akses ke rute yang dilindungi.
‫Oke?
‫Karena itulah yang benar-benar dilakukan selanjutnya.
‫Selanjutnya membawa kita ke
‫middleware berikutnya, yang biasanya, kemudian, pengendali rute itu
‫sendiri, jadi yang mengirim kembali data yang dilindungi.
‫Oke.
‫Hanya satu hal
‫terakhir yang ingin kami lakukan di sini adalah memasukkan seluruh data pengguna pada permintaan.
‫Jadi kita cukup mengatakan, req, so request, . pengguna akan sama dengan pengguna
‫baru.
‫Oke.
‫Dan sekali
‫lagi, tentu saja,
‫kode hanya mencapai titik ini jika semuanya benar.
‫Oke?
‫Jadi, ini di
‫sini mungkin berguna di beberapa titik di masa depan.
‫Besar.
‫Mari kita uji ini sekali lagi.
‫Dan pada dasarnya, perubahan ini di masa lalu sekarang.
‫Jadi, token yang kita miliki di sini, atau sebenarnya, saya
‫dapat menggunakan kembali
‫token ini saja daripada mencatatnya lagi.
‫Tapi bagaimanapun, token ini
‫dikeluarkan setelah kata sandi diubah.
‫Jadi, token ini sekarang harus berfungsi.
‫Jadi mari kita benar-benar masuk
‫lagi dan mencobanya dengan token ini.
‫Dan memang, kami mendapatkan akses.
‫Sekarang, pindah ke Kompas untuk mengubah tanggal itu.
‫Oke.
‫Mari kita taruh satu bulan kemudian.
‫Jadi, itu sebenarnya akan terjadi di
‫masa depan, jadi setidaknya, di masa depan saya ketika saya merekam video ini.
‫Tentu saja, Anda akan melakukan ini di lain waktu.
‫Jadi, untuk menguji ini, harap letakkan ini di masa depan Anda.
‫Jadi di masa depan tanggal di mana Anda
‫menonton video ini.
‫Jadi kalau saya
‫sekarang kembali ke Postman dan login lagi, oke, jadi kalau saya login
‫lagi sekarang dan mencoba mengakses rute
‫itu, nah, token ini akan
‫dikeluarkan, pada dasarnya, setelah kata sandi diubah.
‫Atau sebenarnya sebelum password diubah.
‫Jadi, maaf atas kebingungan itu.
‫Jadi kata sandi diubah pada 30
‫Mei, tetapi token ini dikeluarkan pada tanggal 2 Mei, dan sebelumnya.
‫Jadi pada dasarnya, sekarang seolah-olah pengguna telah mengubah kata
‫sandi mereka setelah token dikeluarkan.
‫Jadi, itulah situasi di mana kami tidak ingin memberikan akses ke
‫rute yang dilindungi.
‫Jadi, ini sekarang harus mencerminkan itu.
‫Dan memang, pengguna baru saja mengubah
‫kata sandi, silakan masuk lagi.
‫Besar.
‫Jadi itu sekarang berfungsi.
‫Jadi middleware pelindung kami sekarang sepenuhnya diimplementasikan.
‫Mari kita singkirkan konsol ini. masuk di sini.
‫Tidak perlu yang itu lagi.
‫Dan oke.
‫Jadi mari kita rekap dengan cepat, dan
‫video ini berjalan sangat
‫lama, sedikit lebih lama dari yang saya harapkan.
‫Tetapi sangat penting
‫untuk memahami dan menjelaskan bagaimana
‫semua ini bekerja dan mengapa ini penting.
‫Jadi, saya lebih suka itu daripada membuat video ini jauh lebih pendek.
‫Tentu saja, saya hanya bisa menulis kodenya, tetapi Anda tidak akan benar-benar mengerti apa
‫yang sedang terjadi.
‫Jadi bagian ini sudah kita pahami.
‫Kemudian bagian ini, saya percaya
‫juga, jadi di sinilah verifikasi terjadi,
‫jadi pada dasarnya melihat apakah muatan token
‫belum dimanipulasi oleh beberapa pihak ketiga yang jahat.
‫Oke?
‫Dan karena kami
‫kemudian mencapai kode ini di sini, itu berarti tidak
‫ada yang mengubah token web JSON, dan oleh karena itu, kami bisa mendapatkan pengguna baru.
‫Jadi pada dasarnya, kita bisa mendapatkan pengguna saat
‫ini, sebut saja pengguna saat ini.
‫Mengapa tidak?
‫Jadi di sini, di sini, dan juga di sini.
‫Oke?
‫Jadi kita bisa
‫mendapatkan currentUser dari ID yang baru saja di-decode dari payload.
‫Sekarang, jika pengguna saat ini tidak
‫ada, jadi inilah yang kami uji di
‫sini, maka dalam hal ini kami tidak ingin
‫memberikan akses ke
‫rute, dan malah membuat kesalahan baru ini.
‫Tapi kalau usernya memang ada,
‫nah, kita lanjut
‫ke poin nomor empat, dimana kemudian kita cek
‫apakah ada perubahan password setelah token dikeluarkan, kan?
‫Dan jika ya, sekali lagi, kami membuat kesalahan baru.
‫Dan jika tidak, maka kami membuatnya sampai ke
‫akhir fungsi middleware,
‫di mana kami kemudian
‫menetapkan pengguna saat ini untuk meminta. pengguna sehingga kami kemudian dapat menggunakannya
‫dalam fungsi middleware berikutnya.
‫Oke?
‫Karena ingat,
‫objek permintaan ini, ini adalah objek yang bergerak,
‫pada dasarnya, dari middleware ke middleware.
‫Jadi, jika kita ingin meneruskan data
‫dari satu middleware ke middleware
‫berikutnya, maka kita cukup meletakkan beberapa hal pada
‫objek request, dan kemudian data itu akan tersedia di lain waktu.
‫Baiklah.
‫Jadi, itu saja.
‫Ini adalah
‫algoritma perlindungan rute yang sangat
‫canggih dan sangat lengkap, pada dasarnya, tetapi saya pikir sangat penting
‫untuk melakukannya sebaik mungkin.
‫Bagaimanapun, senang melihat Anda berhasil sampai di akhir
‫video besar ini, dan sampai
‫jumpa di video berikutnya.