1 00:00:01,140 --> 00:00:03,050 ‫Jonas: Sekarang mari kita lanjutkan 2 00:00:03,050 --> 00:00:04,773 ‫menulis fungsi perlindungan middleware. 3 00:00:06,420 --> 00:00:08,910 ‫Jadi di kuliah terakhir, kita membaca 4 00:00:08,910 --> 00:00:10,990 ‫token dari header otorisasi 5 00:00:10,990 --> 00:00:14,080 ‫dan kemudian memeriksa apakah token itu benar-benar ada. 6 00:00:14,080 --> 00:00:15,023 ‫Jadi di sini. 7 00:00:15,880 --> 00:00:19,890 ‫Dan selanjutnya, kami memiliki langkah verifikasi untuk token. 8 00:00:19,890 --> 00:00:21,880 ‫Dan saya harap Anda ingat 9 00:00:21,880 --> 00:00:24,520 ‫bahwa dalam langkah ini, kami memverifikasi jika 10 00:00:24,520 --> 00:00:27,500 ‫seseorang memanipulasi data atau juga jika token telah kedaluwarsa. 11 00:00:27,500 --> 00:00:31,840 ‫Jadi kita sudah menggunakan, dari paket token web JSON, fungsi assign 12 00:00:31,840 --> 00:00:33,180 ‫function, dan 13 00:00:33,180 --> 00:00:35,623 ‫sekarang kita akan menggunakan fungsi verifikasi. 14 00:00:36,820 --> 00:00:39,333 ‫Jadi seperti sebelumnya, jwt. verifikasi, dan 15 00:00:43,000 --> 00:00:46,630 ‫kemudian di sana, seperti yang dapat Anda bayangkan, kami melewati 16 00:00:46,630 --> 00:00:49,160 ‫token sehingga algoritme dapat membaca muatan dan 17 00:00:49,160 --> 00:00:52,133 ‫kemudian ingat bahwa langkah ini juga membutuhkan rahasia. 18 00:00:53,250 --> 00:00:56,870 ‫Jadi pada dasarnya, untuk membuat tanda tangan tes. 19 00:00:56,870 --> 00:01:00,743 ‫Jadi rahasia itu adalah proses. lingkungan JWT_SECRET. 20 00:01:03,470 --> 00:01:04,610 ‫Ingat bahwa? 21 00:01:04,610 --> 00:01:05,860 ‫Sekarang, sebagai argumen 22 00:01:05,860 --> 00:01:09,003 ‫ketiga, fungsi ini sebenarnya membutuhkan fungsi panggilan balik. 23 00:01:10,090 --> 00:01:12,180 ‫Jadi panggilan balik ini 24 00:01:12,180 --> 00:01:14,850 ‫akan berjalan segera setelah verifikasi selesai. 25 00:01:14,850 --> 00:01:16,840 ‫Jadi Anda melihat bahwa 26 00:01:16,840 --> 00:01:19,564 ‫verifikasi di sini sebenarnya adalah fungsi asinkron. 27 00:01:19,564 --> 00:01:22,540 ‫Jadi itu akan memverifikasi token, dan setelah itu, 28 00:01:22,540 --> 00:01:23,620 ‫setelah selesai, 29 00:01:23,620 --> 00:01:27,040 ‫itu akan memanggil fungsi panggilan balik yang bisa kita tentukan. 30 00:01:27,040 --> 00:01:29,910 ‫Sekarang, kami telah bekerja dengan janji sepanjang waktu, 31 00:01:29,910 --> 00:01:33,159 ‫dan saya tidak benar-benar ingin mematahkan pola itu di sini. 32 00:01:33,159 --> 00:01:37,000 ‫Jadi, kita sebenarnya akan menjanjikan fungsi ini. 33 00:01:37,000 --> 00:01:40,370 ‫Jadi pada dasarnya, untuk membuatnya mengembalikan janji. 34 00:01:40,370 --> 00:01:42,660 ‫Dan dengan begitu, kita kemudian dapat menggunakan 35 00:01:42,660 --> 00:01:45,613 ‫async waiting seperti fungsi async lainnya yang telah kita gunakan. 36 00:01:46,820 --> 00:01:48,050 ‫Jadi untuk 37 00:01:48,050 --> 00:01:51,050 ‫melakukan itu, Node sebenarnya memiliki fungsi promisify bawaan. 38 00:01:51,050 --> 00:01:53,650 ‫Yang perlu kita lakukan untuk 39 00:01:53,650 --> 00:01:56,663 ‫menggunakannya adalah membutuhkan modul util bawaan. 40 00:01:58,695 --> 00:02:00,895 ‫Jadi mari kita lakukan itu tepat di atas, sebenarnya. 41 00:02:02,900 --> 00:02:07,900 ‫Sehingga akan membuat objek bernama util, require... 42 00:02:10,740 --> 00:02:13,400 ‫Baiklah, jadi itu singkatan dari utilitas. 43 00:02:13,400 --> 00:02:15,420 ‫Bukan itu yang saya inginkan. 44 00:02:15,420 --> 00:02:16,960 ‫Jadi itu singkatan dari utilitas. 45 00:02:16,960 --> 00:02:20,300 ‫Dan kemudian di sana, kita akan menggunakan metode promisify. 46 00:02:20,300 --> 00:02:22,900 ‫Tapi karena kita hanya akan menggunakan satu metode itu, sebenarnya 47 00:02:22,900 --> 00:02:24,603 ‫kita bisa melakukannya dengan lebih mudah. 48 00:02:25,578 --> 00:02:26,990 ‫Jadi alih-alih 49 00:02:26,990 --> 00:02:30,610 ‫melakukan ini, kita cukup merusak objek itu dan 50 00:02:30,610 --> 00:02:32,823 ‫mengambil janji langsung dari sana. 51 00:02:35,388 --> 00:02:38,453 ‫Jadi sekali lagi, ini hanya menggunakan destrukturisasi ES6. 52 00:02:41,182 --> 00:02:43,230 ‫Oke, jadi dan sekarang sangat mudah digunakan. 53 00:02:43,230 --> 00:02:46,127 ‫Yang harus kita lakukan hanyalah menelepon promisify. 54 00:02:47,434 --> 00:02:51,463 ‫Jadi janjikan, lalu berikan fungsi di sana. 55 00:02:53,500 --> 00:02:56,080 ‫Jadi sekarang, semua ini di sini adalah fungsi 56 00:02:56,080 --> 00:02:56,970 ‫yang perlu 57 00:02:56,970 --> 00:02:59,190 ‫kita panggil, yang kemudian akan mengembalikan janji. 58 00:02:59,190 --> 00:03:01,810 ‫Jadi di sini, kita sebenarnya memanggil fungsinya. 59 00:03:01,810 --> 00:03:03,900 ‫Dan ini kemudian akan mengembalikan 60 00:03:03,900 --> 00:03:08,300 ‫sebuah janji, jadi kita bisa menunggunya dan menyimpan hasilnya ke dalam sebuah variabel. 61 00:03:08,300 --> 00:03:10,390 ‫Sehingga nilai hasil dari promise tersebut 62 00:03:10,390 --> 00:03:12,350 ‫akan benar-benar menjadi data yang 63 00:03:12,350 --> 00:03:15,823 ‫di-decode, jadi payload yang di-decode dari web token JSON ini. 64 00:03:17,600 --> 00:03:19,360 ‫Jadi izinkan saya menyebutnya diterjemahkan di sini. 65 00:03:19,360 --> 00:03:20,193 ‫Baiklah. 66 00:03:20,193 --> 00:03:23,490 ‫Dan kita bisa menunggu karena kita sebenarnya sudah mengatakan 67 00:03:23,490 --> 00:03:25,453 ‫bahwa itu adalah fungsi asinkron. 68 00:03:27,670 --> 00:03:30,850 ‫Dan sekarang, hanya untuk melihat bahwa itu benar-benar 69 00:03:30,850 --> 00:03:34,730 ‫berfungsi, mari kita log data yang didekodekan ini ke konsol juga. 70 00:03:34,730 --> 00:03:38,143 ‫Dan sebenarnya, kita dapat menghapus konsol ini. keluar dari token. 71 00:03:39,050 --> 00:03:40,400 ‫Yang tidak kita butuhkan lagi. 72 00:03:42,140 --> 00:03:46,560 ‫Jadi mari kita coba mengirim permintaan ini lagi, dan ya, 73 00:03:46,560 --> 00:03:49,990 ‫tetapi kali ini sebenarnya mengaktifkan header otorisasi 74 00:03:49,990 --> 00:03:54,850 ‫ini sehingga kami mengirim token web JSON bersama dengan permintaan tersebut. 75 00:03:54,850 --> 00:03:55,940 ‫Jadi yang mengirimnya. 76 00:03:55,940 --> 00:03:58,540 ‫Dan sekarang, memang, kami mendapatkan akses ke data, 77 00:03:58,540 --> 00:04:02,070 ‫dan oleh karena itu, kami sekarang memiliki akses ke rute yang dilindungi. 78 00:04:02,070 --> 00:04:02,903 ‫Oke? 79 00:04:02,903 --> 00:04:06,203 ‫Tapi yang ingin saya lihat adalah objek yang didekodekan di sini. 80 00:04:07,230 --> 00:04:09,910 ‫Jadi ini di sini harus menjadi ID pengguna. 81 00:04:09,910 --> 00:04:12,530 ‫Jadi mari kita lihat lagi di Postman. 82 00:04:12,530 --> 00:04:13,423 ‫Jadi 62a42. 83 00:04:15,520 --> 00:04:18,740 ‫Jadi, memang, di mana kita memilikinya? 84 00:04:18,740 --> 00:04:20,193 ‫Mari kita lihat Kompas. 85 00:04:21,240 --> 00:04:24,813 ‫Dan memang, ID pengguna ini adalah 62a42 ini. 86 00:04:27,160 --> 00:04:29,347 ‫Dan itu berarti bahwa kita benar-benar memiliki 87 00:04:29,347 --> 00:04:31,340 ‫muatan yang benar di sini. 88 00:04:31,340 --> 00:04:33,420 ‫Jadi pada dasarnya, ID pengguna yang benar. 89 00:04:33,420 --> 00:04:36,460 ‫Kami kemudian juga memiliki stempel waktu 90 00:04:36,460 --> 00:04:39,500 ‫tanggal pembuatan dan tanggal kedaluwarsa token. 91 00:04:39,500 --> 00:04:40,700 ‫Jadi ini bekerja. 92 00:04:40,700 --> 00:04:43,710 ‫Tapi sekarang mari kita coba memanipulasi payload token 93 00:04:43,710 --> 00:04:44,563 ‫ini. 94 00:04:47,088 --> 00:04:49,090 ‫Jadi mari kita salin di sini lagi. 95 00:04:49,090 --> 00:04:52,443 ‫Tapi kemudian saya akan pergi ke debugger JWT. 96 00:04:54,640 --> 00:04:57,023 ‫Jadi sekali lagi, di jwt. saya 97 00:05:00,290 --> 00:05:02,363 ‫Jadi mari kita ambil ini. 98 00:05:03,310 --> 00:05:06,010 ‫Dan sekarang yang akan saya lakukan adalah mengubah beberapa data 99 00:05:06,010 --> 00:05:09,260 ‫di sini dan itu kemudian akan mengubah token yang disandikan di sini, yang 100 00:05:09,260 --> 00:05:11,010 ‫kemudian dapat saya lanjutkan dan salin. 101 00:05:12,420 --> 00:05:14,693 ‫Jadi mari kita ganti saja, sebenarnya, 102 00:05:15,580 --> 00:05:19,050 ‫saya hanya akan mengganti dua angka ini di sini 103 00:05:19,050 --> 00:05:20,940 ‫dengan sesuatu yang berbeda. 104 00:05:20,940 --> 00:05:23,590 ‫Jadi, seperti yang Anda lihat, ini mengubah token di sini. 105 00:05:23,590 --> 00:05:26,040 ‫Jadi sekarang, saya benar-benar akan mencoba mendapatkan 106 00:05:26,040 --> 00:05:27,470 ‫akses ke rute yang 107 00:05:27,470 --> 00:05:30,373 ‫dilindungi itu menggunakan token web JSON yang dimanipulasi ini. 108 00:05:31,460 --> 00:05:33,133 ‫Oke, masuk akal? 109 00:05:34,100 --> 00:05:37,023 ‫Jadi hanya untuk melihat apakah itu berfungsi dengan benar. 110 00:05:38,632 --> 00:05:39,970 ‫Jadi saya menyalin yang 111 00:05:39,970 --> 00:05:42,660 ‫ini di sini sekarang dan menempelkan yang lain ini. 112 00:05:42,660 --> 00:05:47,310 ‫Jadi, jika saya sekarang mengirim permintaan ini, maka kami mendapatkan kesalahan. 113 00:05:47,310 --> 00:05:48,250 ‫Sangat bagus. 114 00:05:48,250 --> 00:05:50,843 ‫Jadi, kami melihat nama kesalahannya adalah JsonWebTokenError, dan 115 00:05:51,840 --> 00:05:54,220 ‫kami memiliki tanda tangan yang tidak valid. 116 00:05:54,220 --> 00:05:55,160 ‫Sangat bagus. 117 00:05:55,160 --> 00:05:57,650 ‫Itulah yang kami cari. 118 00:05:57,650 --> 00:06:00,210 ‫Jadi itulah salah satu dari dua kesalahan yang bisa terjadi. 119 00:06:00,210 --> 00:06:02,853 ‫Yang lainnya adalah bahwa token telah kedaluwarsa. 120 00:06:04,359 --> 00:06:07,180 ‫Jadi yang ini disebut JsonWebTokenError, dan 121 00:06:07,180 --> 00:06:10,890 ‫sebenarnya, mari kita lanjutkan dan tangani kesalahan ini sekarang. 122 00:06:10,890 --> 00:06:12,240 ‫Dan cara yang 123 00:06:12,240 --> 00:06:16,470 ‫bisa kita lakukan adalah dengan menambahkan blok try-catch di sini. 124 00:06:16,470 --> 00:06:17,460 ‫Benar? 125 00:06:17,460 --> 00:06:19,600 ‫Jadi setelah melakukan kode ini, kita 126 00:06:19,600 --> 00:06:21,510 ‫bisa memperkenalkan blok try, 127 00:06:21,510 --> 00:06:24,260 ‫dan kemudian di catch, kita akan membuat kesalahan 128 00:06:24,260 --> 00:06:26,290 ‫yang akan dikirim ke klien. 129 00:06:26,290 --> 00:06:28,070 ‫Sekarang, alih-alih melakukannya seperti 130 00:06:28,070 --> 00:06:30,970 ‫itu, saya sebenarnya ingin menggunakan middleware penanganan kesalahan 131 00:06:30,970 --> 00:06:33,290 ‫global kami untuk melakukannya untuk kami. 132 00:06:33,290 --> 00:06:35,850 ‫Jadi kami tidak suka melakukan penanganan kesalahan di sini 133 00:06:35,850 --> 00:06:37,220 ‫di fungsi middleware kami. 134 00:06:37,220 --> 00:06:41,140 ‫Sebagai gantinya, kami biasanya mendelegasikannya ke pengontrol kesalahan. 135 00:06:41,140 --> 00:06:43,940 ‫Jadi, mari lakukan hal yang sama persis di sini. 136 00:06:43,940 --> 00:06:46,710 ‫Jadi pengontrol kesalahan. 137 00:06:46,710 --> 00:06:48,600 ‫Dan kemudian sebenarnya hal yang sama persis seperti 138 00:06:48,600 --> 00:06:50,930 ‫yang kita miliki dengan kesalahan kita yang lain di sini. 139 00:06:50,930 --> 00:06:54,210 ‫Jadi misalnya kesalahan validasi datang dari luwak, jadi 140 00:06:54,210 --> 00:06:55,670 ‫dari perpustakaan lain. 141 00:06:55,670 --> 00:06:59,060 ‫Dan sekarang, kesalahan ini sebenarnya berasal dari perpustakaan 142 00:06:59,060 --> 00:07:02,180 ‫lain dan juga memiliki namanya sendiri. 143 00:07:02,180 --> 00:07:03,470 ‫Jadi mari kita dapatkan itu. 144 00:07:03,470 --> 00:07:04,820 ‫Dan itu JsonWebTokenError. 145 00:07:06,900 --> 00:07:07,940 ‫Baiklah. 146 00:07:07,940 --> 00:07:09,923 ‫Jadi, mari kita lakukan yang sangat mirip di sini. 147 00:07:11,850 --> 00:07:12,683 ‫Jadi jika. namanya 148 00:07:15,477 --> 00:07:19,310 ‫ini, maka kesalahan harus sama dengan menangani kesalahan. 149 00:07:19,310 --> 00:07:23,463 ‫Oke. 150 00:07:27,010 --> 00:07:27,843 ‫Jadi mari kita 151 00:07:27,843 --> 00:07:30,430 ‫lanjutkan dan buat fungsi ini, sebenarnya, di suatu tempat di sini. 152 00:07:30,430 --> 00:07:31,953 ‫Dan yang satu ini sebenarnya sangat sederhana. 153 00:07:35,782 --> 00:07:37,810 ‫Yang dilakukannya hanyalah mengambil kesalahan dan 154 00:07:37,810 --> 00:07:39,760 ‫kemudian mengembalikan AppError baru. 155 00:07:39,760 --> 00:07:41,433 ‫Oke? 156 00:07:44,480 --> 00:07:45,320 ‫Jadi dalam 157 00:07:45,320 --> 00:07:48,950 ‫fungsi panah ES6 ini, seperti yang saya harap Anda ketahui, kita dapat menulis 158 00:07:48,950 --> 00:07:50,790 ‫satu baris ini di mana kita bahkan 159 00:07:50,790 --> 00:07:53,610 ‫tidak perlu menentukan kurung kurawal dan juga kata kunci return. 160 00:07:53,610 --> 00:07:55,610 ‫Jadi ini akan secara otomatis 161 00:07:55,610 --> 00:07:58,670 ‫dan implisit mengembalikan apa pun yang kita taruh di sini. 162 00:07:58,670 --> 00:08:00,123 ‫Benar? 163 00:08:01,010 --> 00:08:01,843 ‫Jadi, 164 00:08:01,843 --> 00:08:04,763 ‫yang ingin kami sampaikan di sini hanyalah, token tidak 165 00:08:05,980 --> 00:08:07,273 ‫valid, silakan masuk lagi. 166 00:08:09,580 --> 00:08:12,640 ‫Dan kemudian, kode kesalahan, seperti sebelumnya, adalah 167 00:08:12,640 --> 00:08:15,000 ‫401 untuk Tidak Diotorisasi. 168 00:08:15,000 --> 00:08:17,463 ‫Sekarang, ini hanya berfungsi, ingat, dalam produksi. 169 00:08:19,497 --> 00:08:22,410 ‫Jadi, jika kita melakukan ini sekarang lagi, maka kita 170 00:08:22,410 --> 00:08:24,883 ‫akan mendapatkan hal yang sama persis. 171 00:08:24,883 --> 00:08:27,730 ‫Jadi, mari kita kembali ke sini dan 172 00:08:27,730 --> 00:08:29,890 ‫menjalankan ini dalam produksi. 173 00:08:29,890 --> 00:08:32,340 ‫Jadi npm jalankan start:production. 174 00:08:32,340 --> 00:08:37,340 ‫Ya, begitu saja. 175 00:08:39,470 --> 00:08:40,733 ‫Jadi jika kita mencoba ini 176 00:08:41,650 --> 00:08:43,890 ‫sekarang lagi, mari kita lihat apakah kita mendapatkan kesalahan kita. 177 00:08:43,890 --> 00:08:45,630 ‫Dan memang, kami melakukannya. 178 00:08:45,630 --> 00:08:47,840 ‫Jadi jika, saat ini, pengguna dalam produksi 179 00:08:47,840 --> 00:08:50,040 ‫mencoba mengakses aplikasi kami dengan token 180 00:08:50,040 --> 00:08:52,930 ‫yang tidak valid, maka mereka hanya mendapatkan pesan kesalahan ini. 181 00:08:52,930 --> 00:08:55,890 ‫Baiklah? 182 00:08:55,890 --> 00:08:57,120 ‫Jadi itulah kesalahan pertama yang bisa kita dapatkan. 183 00:08:57,120 --> 00:08:59,920 ‫Tetapi satu lagi adalah bahwa pengguna mencoba 184 00:08:59,920 --> 00:09:01,560 ‫mengakses aplikasi dengan 185 00:09:01,560 --> 00:09:03,500 ‫token yang sudah kedaluwarsa. 186 00:09:03,500 --> 00:09:06,147 ‫Jadi, sekarang mari kita coba membuat kesalahan itu. 187 00:09:06,147 --> 00:09:08,733 ‫Dan untuk melakukan itu, saya 188 00:09:09,683 --> 00:09:13,080 ‫akan mengubah waktu yang dibutuhkan token untuk kedaluwarsa. 189 00:09:13,080 --> 00:09:14,943 ‫Jadi sekarang, kita punya 90 hari. 190 00:09:17,811 --> 00:09:19,190 ‫Mari kita lakukan, seperti, lima detik. 191 00:09:19,190 --> 00:09:22,183 ‫Oke. 192 00:09:23,078 --> 00:09:23,911 ‫Berikan simpanan. 193 00:09:23,911 --> 00:09:24,870 ‫Dan sekarang coba masuk lagi. 194 00:09:24,870 --> 00:09:26,823 ‫Jadi mari kita simpan yang ini di sini juga. 195 00:09:28,090 --> 00:09:30,943 ‫Jadi, di pengguna, lalu masuk. 196 00:09:32,920 --> 00:09:37,043 ‫Jadi kita bisa login, dan itu akan memberi kita token 197 00:09:39,060 --> 00:09:43,100 ‫baru, tapi token ini hanya berlaku selama lima detik. 198 00:09:43,100 --> 00:09:46,100 ‫Jadi, lima detik ini seharusnya sudah berlalu pada saat ini. 199 00:09:46,100 --> 00:09:49,550 ‫Jadi sekarang saya akan menyalin token ini dan mencoba mengakses 200 00:09:49,550 --> 00:09:51,690 ‫rute terlindungi kami menggunakan token itu. 201 00:09:51,690 --> 00:09:55,713 ‫Jadi tempel di sini. 202 00:09:58,529 --> 00:09:59,362 ‫Dan sekarang, mari kita lihat apa yang kita dapatkan. 203 00:09:59,362 --> 00:10:01,630 ‫Dan sebenarnya, untuk beberapa alasan, itu berhasil. 204 00:10:01,630 --> 00:10:04,280 ‫Jadi mari kita lihat debugger JWT kita lagi. 205 00:10:04,280 --> 00:10:08,593 ‫Dan dikatakan, dibuat tanggal 2 Mei, tetapi hanya kedaluwarsa 206 00:10:11,620 --> 00:10:14,160 ‫pada tanggal 31 Juli. 207 00:10:14,160 --> 00:10:16,720 ‫Jadi ada yang salah dalam pembuatan token itu, saya kira. 208 00:10:16,720 --> 00:10:21,023 ‫Jadi, mari kita ubah ini di sini lagi. 209 00:10:22,140 --> 00:10:23,810 ‫Dan aku hanya akan menempatkan lima di sini. 210 00:10:23,810 --> 00:10:25,993 ‫Jadi, lima itu kemudian harus 211 00:10:27,270 --> 00:10:30,340 ‫berdiri selama lima milidetik, atau saya bahkan bisa, seperti, 212 00:10:30,340 --> 00:10:32,630 ‫menempatkan 5000, yang kemudian menjadi lima detik. 213 00:10:32,630 --> 00:10:34,733 ‫Oke. 214 00:10:37,680 --> 00:10:38,890 ‫Jadi biarkan saya menyimpannya sekarang lagi untuk me-restart server. 215 00:10:38,890 --> 00:10:42,363 ‫Coba lagi. 216 00:10:43,240 --> 00:10:44,570 ‫Jadi login lagi di sini. 217 00:10:44,570 --> 00:10:46,113 ‫Baiklah. 218 00:10:47,680 --> 00:10:48,600 ‫Jadi sekarang yang 219 00:10:48,600 --> 00:10:52,930 ‫perlu kita lakukan pada dasarnya adalah menunggu lima detik, dan waktu itu seharusnya sudah berlalu pada saat ini. 220 00:10:52,930 --> 00:10:56,933 ‫Tempel di sini lagi. 221 00:11:00,230 --> 00:11:01,500 ‫Dan mari kita pergi. 222 00:11:01,500 --> 00:11:03,560 ‫Dan memang, kami mendapatkan kesalahan. 223 00:11:03,560 --> 00:11:05,860 ‫Sekarang ingat bagaimana ini pada 224 00:11:05,860 --> 00:11:09,850 ‫dasarnya adalah kesalahan standar yang kami dapatkan jika kami tidak 225 00:11:09,850 --> 00:11:13,230 ‫menangani kesalahan itu dengan benar dalam penanganan kesalahan kami. 226 00:11:13,230 --> 00:11:14,700 ‫Benar? 227 00:11:14,700 --> 00:11:15,750 ‫Jadi mari kita lihat kesalahannya. 228 00:11:15,750 --> 00:11:18,840 ‫Dan sebenarnya, kami memilikinya di sini di konsol. 229 00:11:18,840 --> 00:11:21,350 ‫Jadi mari kita lihat dari mana asalnya. 230 00:11:21,350 --> 00:11:24,620 ‫Dan ya, itu berasal dari tempat ini. 231 00:11:24,620 --> 00:11:26,673 ‫Jadi ini adalah kasus di mana kita memiliki kesalahan yang tidak diketahui. 232 00:11:27,760 --> 00:11:31,690 ‫Ingat, jadi kesalahan yang tidak ditandai sebagai kesalahan 233 00:11:31,690 --> 00:11:34,090 ‫operasional, dan karena itu kami 234 00:11:34,090 --> 00:11:35,640 ‫ingin mencatatnya. 235 00:11:35,640 --> 00:11:37,543 ‫Jadi kami mencatatnya di sini dan kemudian 236 00:11:38,500 --> 00:11:39,650 ‫kami mengirim pesan kesalahan umum 237 00:11:39,650 --> 00:11:42,150 ‫ini ke klien, jadi yang baru saja kami lihat 238 00:11:42,150 --> 00:11:43,270 ‫di Tukang Pos. 239 00:11:43,270 --> 00:11:45,610 ‫Tapi di sini kita sebenarnya rincian dari kesalahan ini. 240 00:11:45,610 --> 00:11:48,100 ‫Jadi, yang ini bernama TokenExpiredError. 241 00:11:48,100 --> 00:11:51,480 ‫Baiklah. 242 00:11:51,480 --> 00:11:52,313 ‫Jadi, sekarang mari kita tangani yang ini juga. 243 00:11:52,313 --> 00:11:55,360 ‫Jadi saya menyalinnya sekarang, dan kemudian membuat yang 244 00:11:55,360 --> 00:11:57,171 ‫lain jika di sini. 245 00:11:57,171 --> 00:12:02,171 ‫Jadi jika kesalahan. name sama dengan yang 246 00:12:02,300 --> 00:12:07,300 ‫ini, kalau 247 00:12:08,980 --> 00:12:14,461 ‫begitu, katakanlah, handleJWTExpiredError dengan panah. 248 00:12:18,640 --> 00:12:20,233 ‫Mari kita salin dan taruh di sini. 249 00:12:22,568 --> 00:12:25,750 ‫Dan ini, tentu saja, sangat mirip dengan yang sebelumnya. 250 00:12:33,186 --> 00:12:37,770 ‫Token Anda telah kedaluwarsa. 251 00:12:37,770 --> 00:12:40,493 ‫Silakan masuk lagi. 252 00:12:43,940 --> 00:12:45,193 ‫Dan lagi, dengan kode kesalahan 401. 253 00:12:48,670 --> 00:12:51,423 ‫Oke, mari kita coba lagi. 254 00:12:52,360 --> 00:12:54,270 ‫Jadi, itulah pesan kesalahan yang seharusnya 255 00:12:54,270 --> 00:12:56,043 ‫sekarang kita lihat di sini. 256 00:12:56,043 --> 00:12:58,023 ‫Baiklah. 257 00:12:59,430 --> 00:13:00,263 ‫Dan memang, itu. 258 00:13:00,263 --> 00:13:01,263 ‫Besar. 259 00:13:02,480 --> 00:13:03,520 ‫Mari selesaikan prosesnya di 260 00:13:03,520 --> 00:13:04,980 ‫sini dan mulai dalam mode dev, tentu saja. 261 00:13:04,980 --> 00:13:07,560 ‫Jadi npm 262 00:13:07,560 --> 00:13:10,213 ‫mulai, dan baiklah. 263 00:13:11,700 --> 00:13:13,740 ‫Jadi yang ini, kita tidak perlu lagi, jadi mari kita tutup. 264 00:13:13,740 --> 00:13:17,460 ‫Atau sebenarnya, mari kita perbaiki kesalahan kecil ini di sini, karena memang kami 265 00:13:17,460 --> 00:13:19,880 ‫tidak menggunakan kesalahan ini di sini sama sekali. 266 00:13:19,880 --> 00:13:23,113 ‫Jadi mari kita singkirkan itu. 267 00:13:24,170 --> 00:13:25,423 ‫Dan kemudian di bawah sini, kita tidak perlu melewatinya di sana. 268 00:13:29,260 --> 00:13:32,063 ‫Dingin. 269 00:13:39,290 --> 00:13:40,123 ‫Kami, tentu saja, juga perlu mengubah ini kembali ke 90 hari. 270 00:13:41,060 --> 00:13:44,423 ‫Baiklah. 271 00:13:47,200 --> 00:13:48,040 ‫Jadi, 272 00:13:48,040 --> 00:13:51,560 ‫untuk memastikannya, mari login lagi di sini, 273 00:13:51,560 --> 00:13:52,803 ‫salin tokennya, 274 00:13:53,830 --> 00:13:55,513 ‫dan taruh di sini. 275 00:13:56,680 --> 00:13:59,050 ‫Sekarang, proses menyalin token di sini dan 276 00:13:59,050 --> 00:14:01,750 ‫kemudian menempelkannya di sini di header ini mungkin 277 00:14:01,750 --> 00:14:04,190 ‫tampak agak aneh, dan sebenarnya kami akan memperbaikinya 278 00:14:04,190 --> 00:14:05,640 ‫di salah satu 279 00:14:05,640 --> 00:14:07,230 ‫video mendatang sehingga pada dasarnya, 280 00:14:07,230 --> 00:14:09,030 ‫proses ini terjadi secara otomatis. 281 00:14:09,030 --> 00:14:12,070 ‫Tapi sekarang, yang penting adalah itu benar-benar 282 00:14:12,070 --> 00:14:13,970 ‫kembali bekerja sekarang. 283 00:14:13,970 --> 00:14:16,750 ‫Jadi kita benar-benar bisa menyingkirkan konsol ini. login di sini dan lanjutkan 284 00:14:16,750 --> 00:14:21,027 ‫ke langkah berikutnya. 285 00:14:21,027 --> 00:14:24,250 ‫Dan kita benar-benar bisa berhenti di sini sekarang jika kita mau. 286 00:14:24,250 --> 00:14:27,010 ‫Dan lagi, sebagian besar tutorial yang akan 287 00:14:27,010 --> 00:14:30,130 ‫Anda temukan di sana, pada kenyataannya, akan berhenti di sini. 288 00:14:30,130 --> 00:14:32,420 ‫Tapi ini belum cukup aman. 289 00:14:32,420 --> 00:14:35,210 ‫Jadi misalnya, bagaimana jika pengguna 290 00:14:35,210 --> 00:14:37,550 ‫telah dihapus sementara itu? 291 00:14:37,550 --> 00:14:39,840 ‫Jadi tokennya akan tetap ada, tapi kalau 292 00:14:39,840 --> 00:14:41,800 ‫usernya sudah tidak ada, ya 293 00:14:41,800 --> 00:14:43,900 ‫kita sebenarnya tidak mau log in kan? 294 00:14:43,900 --> 00:14:47,780 ‫Atau lebih buruk lagi, bagaimana jika pengguna 295 00:14:47,780 --> 00:14:50,070 ‫benar-benar mengubah kata sandinya 296 00:14:50,070 --> 00:14:52,130 ‫setelah token dikeluarkan? 297 00:14:52,130 --> 00:14:54,360 ‫Yah, itu juga seharusnya tidak berhasil, bukan? 298 00:14:54,360 --> 00:14:56,950 ‫Misalnya, bayangkan seseorang 299 00:14:56,950 --> 00:15:00,750 ‫mencuri token web JSON dari pengguna. 300 00:15:00,750 --> 00:15:01,870 ‫Tapi kemudian, 301 00:15:01,870 --> 00:15:04,380 ‫untuk melindunginya, pengguna mengubah kata sandinya. 302 00:15:04,380 --> 00:15:06,770 ‫Jadi, tentu saja, token lama yang dikeluarkan 303 00:15:06,770 --> 00:15:09,270 ‫sebelum perubahan kata sandi seharusnya tidak berlaku lagi. 304 00:15:09,270 --> 00:15:12,940 ‫Jadi tidak boleh diterima untuk mengakses rute yang dilindungi. 305 00:15:12,940 --> 00:15:16,906 ‫Jadi, hal-hal seperti itulah yang akan kita terapkan 306 00:15:16,906 --> 00:15:19,550 ‫di langkah ketiga dan keempat. 307 00:15:19,550 --> 00:15:22,060 ‫Jadi hal pertama yang harus dilakukan adalah memeriksa apakah pengguna 308 00:15:22,060 --> 00:15:23,120 ‫benar-benar masih ada. 309 00:15:23,120 --> 00:15:26,060 ‫Jadi, yang itu harus yang paling mudah. 310 00:15:26,060 --> 00:15:28,690 ‫Jadi katakan saja, Pengguna. temukanById. 311 00:15:28,690 --> 00:15:32,463 ‫Jadi, inilah mengapa kami sebenarnya memiliki 312 00:15:36,568 --> 00:15:38,440 ‫ID di payload, karena 313 00:15:38,440 --> 00:15:40,540 ‫kami sekarang dapat menggunakan ID itu 314 00:15:40,540 --> 00:15:42,767 ‫dan meminta pengguna hanya menggunakan ID itu. 315 00:15:42,767 --> 00:15:46,530 ‫Jadi diterjemahkan. Indo. 316 00:15:46,530 --> 00:15:49,390 ‫Baiklah? 317 00:15:49,390 --> 00:15:50,223 ‫Jadi yang kemudian harus menemukan pengguna baru. 318 00:15:50,223 --> 00:15:53,110 ‫Dan tentu saja, kita perlu menunggu itu dan 319 00:15:53,110 --> 00:15:55,860 ‫kemudian menyimpannya ke dalam sebuah variabel. 320 00:15:55,860 --> 00:15:59,560 ‫Saya menyebutnya pengguna baru. 321 00:15:59,560 --> 00:16:01,480 ‫Baiklah? 322 00:16:03,148 --> 00:16:03,981 ‫Karena memang bukan pengguna baru. 323 00:16:03,981 --> 00:16:05,460 ‫Itu hanya ketika kita membuatnya. 324 00:16:05,460 --> 00:16:07,300 ‫Tapi ini sebenarnya bukan yang baru, ini benar-benar 325 00:16:07,300 --> 00:16:09,030 ‫hanya pengguna berdasarkan ID yang didekodekan. 326 00:16:09,030 --> 00:16:12,980 ‫Oke? 327 00:16:12,980 --> 00:16:13,870 ‫Dan hal 328 00:16:13,870 --> 00:16:16,833 ‫ini bisa kita lakukan agar bisa 100% yakin bahwa 329 00:16:16,833 --> 00:16:18,990 ‫ID tersebut benar-benar benar, karena jika 330 00:16:18,990 --> 00:16:22,460 ‫kita membuatnya sampai titik kode di sini maka itu berarti proses 331 00:16:22,460 --> 00:16:25,110 ‫verifikasi yang kita lakukan sebelumnya di sini berhasil. 332 00:16:25,110 --> 00:16:28,200 ‫Jika tidak, ini akan menyebabkan kesalahan 333 00:16:28,200 --> 00:16:30,220 ‫yang kemudian akan mencegah 334 00:16:30,220 --> 00:16:31,490 ‫fungsi melanjutkan. 335 00:16:31,490 --> 00:16:33,410 ‫Jadi, sekali lagi, 336 00:16:33,410 --> 00:16:36,660 ‫proses verifikasi ini bertugas memverifikasi jika tidak 337 00:16:36,660 --> 00:16:38,620 ‫ada yang mengubah ID yang 338 00:16:38,620 --> 00:16:40,900 ‫ada di payload token ini. 339 00:16:40,900 --> 00:16:43,033 ‫Jadi, karena itu, kami 340 00:16:43,970 --> 00:16:46,970 ‫dapat 100% yakin bahwa pengguna yang kami berikan 341 00:16:46,970 --> 00:16:50,600 ‫JWT adalah orang yang ID-nya sekarang berada di dalam 342 00:16:50,600 --> 00:16:52,790 ‫payload yang didekode, jadi yang ini. 343 00:16:52,790 --> 00:16:56,810 ‫Oke? 344 00:16:56,810 --> 00:16:57,690 ‫Jadi proses verifikasi sangat penting. 345 00:16:57,690 --> 00:17:00,440 ‫Ini benar-benar yang membuat semua ini berhasil. 346 00:17:00,440 --> 00:17:02,440 ‫Bagaimanapun, sekarang yang perlu kita lakukan adalah 347 00:17:04,730 --> 00:17:06,410 ‫memeriksa apakah memang ada freshUser. 348 00:17:06,410 --> 00:17:09,570 ‫Dan jika tidak, maka, tentu saja, kami 349 00:17:09,570 --> 00:17:11,570 ‫akan mengembalikan kesalahan baru. 350 00:17:11,570 --> 00:17:13,844 ‫Jadi jika tidak ada pengguna 351 00:17:13,844 --> 00:17:16,577 ‫baru, kembalilah dari middleware ini dan panggil 352 00:17:19,880 --> 00:17:22,100 ‫yang berikutnya dengan kesalahan. 353 00:17:22,100 --> 00:17:24,083 ‫Jadi ini adalah pola yang telah 354 00:17:24,920 --> 00:17:27,100 ‫kita lihat berulang kali pada saat ini, bukan? 355 00:17:27,100 --> 00:17:29,403 ‫Jadi tokennya sudah tidak 356 00:17:30,350 --> 00:17:31,490 ‫ada. 357 00:17:35,470 --> 00:17:39,173 ‫Dan sebenarnya, itu sebaliknya. 358 00:17:40,810 --> 00:17:42,750 ‫Jadi sebenarnya, pengguna 359 00:17:42,750 --> 00:17:45,200 ‫milik token sudah tidak ada lagi. 360 00:17:47,170 --> 00:17:48,680 ‫Benar? 361 00:17:48,680 --> 00:17:49,513 ‫Dan kemudian, 401. 362 00:17:49,513 --> 00:17:51,297 ‫Oke. 363 00:17:53,780 --> 00:17:54,920 ‫Jadi mari kita uji ini sekali lagi. 364 00:17:54,920 --> 00:17:57,860 ‫Dan mari kita buat pengguna baru untuk itu. 365 00:17:57,860 --> 00:18:00,843 ‫Jadi cukup uji dengan kata sandi yang sama jadi kami selalu menggunakan 366 00:18:02,620 --> 00:18:04,880 ‫kata sandi yang sama di sini hanya untuk 367 00:18:04,880 --> 00:18:06,590 ‫membuat pengujian kami sedikit lebih mudah. 368 00:18:06,590 --> 00:18:09,160 ‫Dan saya tahu bahwa semua pengujian di sini 369 00:18:09,160 --> 00:18:11,070 ‫membuat video memakan waktu yang sangat 370 00:18:11,070 --> 00:18:14,440 ‫lama, tetapi tentu saja, sangat penting bagi kami untuk menguji semua 371 00:18:14,440 --> 00:18:15,900 ‫yang kami lakukan, 372 00:18:15,900 --> 00:18:17,950 ‫terutama dalam topik penting seperti autentikasi. 373 00:18:17,950 --> 00:18:21,713 ‫Jadi saya sekarang menggunakan JWT ini di sini, jadi 374 00:18:23,071 --> 00:18:27,780 ‫saya menempelkannya di sini, tetapi tentu saja, sebelum mengirim permintaan, saya akan 375 00:18:27,780 --> 00:18:30,630 ‫melanjutkan dan menghapus pengguna itu segera. 376 00:18:30,630 --> 00:18:33,573 ‫Oke? 377 00:18:34,650 --> 00:18:35,690 ‫Jadi sekali lagi, 378 00:18:35,690 --> 00:18:37,690 ‫anggaplah seseorang membuat pengguna lalu masuk, 379 00:18:37,690 --> 00:18:40,020 ‫dan katakanlah, setelah beberapa waktu, pengguna tersebut dihapus. 380 00:18:40,020 --> 00:18:43,500 ‫Tetapi sementara itu, seseorang bisa mendapatkan akses ke 381 00:18:43,500 --> 00:18:44,333 ‫JWT 382 00:18:44,333 --> 00:18:47,410 ‫itu, dan sekarang dapat mencoba masuk sebagai 383 00:18:47,410 --> 00:18:50,030 ‫pengguna yang sebenarnya sudah dihapus. 384 00:18:50,030 --> 00:18:52,580 ‫Jadi, sekali lagi, kita tidak boleh membiarkan itu terjadi. 385 00:18:52,580 --> 00:18:55,520 ‫Jadi izinkan saya menghapus pengguna ini di sini sekarang. 386 00:18:55,520 --> 00:18:57,713 ‫Dan di sana kita pergi. 387 00:18:59,010 --> 00:18:59,943 ‫Jadi, mari kita uji sekarang. 388 00:19:01,720 --> 00:19:03,630 ‫Dan lagi, perlu diingat bahwa pengguna 389 00:19:03,630 --> 00:19:07,060 ‫milik ID yang ada di payload ini sekarang sudah tidak ada lagi. 390 00:19:07,060 --> 00:19:10,690 ‫Jadi mari kita lihat. 391 00:19:10,690 --> 00:19:12,040 ‫Dan memang, kami mendapatkan pesan kesalahan yang baru saja kami buat. 392 00:19:12,040 --> 00:19:16,313 ‫Jadi yang satu itu juga berfungsi. 393 00:19:17,520 --> 00:19:20,200 ‫Dan mari kita pergi ke yang terakhir. 394 00:19:20,200 --> 00:19:22,400 ‫Jadi langkah nomor empat, periksa apakah pengguna baru 395 00:19:22,400 --> 00:19:23,830 ‫saja mengubah kata sandi mereka. 396 00:19:23,830 --> 00:19:27,070 ‫Jadi pada dasarnya, setelah token dikeluarkan. 397 00:19:27,070 --> 00:19:30,100 ‫Dan untuk mengimplementasikan pengujian ini, kita sebenarnya akan membuat 398 00:19:30,100 --> 00:19:31,550 ‫metode instance lain. 399 00:19:31,550 --> 00:19:34,260 ‫Jadi pada dasarnya, metode 400 00:19:34,260 --> 00:19:37,030 ‫yang akan tersedia di semua dokumen. 401 00:19:37,030 --> 00:19:38,330 ‫Jadi dokumen adalah contoh dari model. 402 00:19:38,330 --> 00:19:41,410 ‫Baiklah? 403 00:19:41,410 --> 00:19:42,243 ‫Dan kami melakukan 404 00:19:42,243 --> 00:19:44,490 ‫ini karena cukup banyak kode yang kami butuhkan untuk verifikasi ini. 405 00:19:44,490 --> 00:19:46,540 ‫Jadi, sebenarnya, kode ini 406 00:19:46,540 --> 00:19:50,040 ‫milik model Pengguna dan bukan milik pengontrol. 407 00:19:50,040 --> 00:19:51,970 ‫Oke? 408 00:19:51,970 --> 00:19:52,803 ‫Jadi, mari kita 409 00:19:52,803 --> 00:19:55,050 ‫lakukan seperti yang kita lakukan sebelumnya untuk memeriksa kata sandi. 410 00:19:55,050 --> 00:19:57,270 ‫Jadi dalam model Pengguna, kami telah 411 00:19:57,270 --> 00:19:59,840 ‫mengimplementasikan metode contoh statis correctPassword ini, ingat? 412 00:19:59,840 --> 00:20:04,710 ‫Jadi, sekarang mari kita buat yang lain. 413 00:20:04,710 --> 00:20:06,903 ‫Jadi userSchema. metode. diubahPasswordAfter. 414 00:20:08,339 --> 00:20:13,339 ‫Jadi fungsi, dan ke dalam 415 00:20:22,390 --> 00:20:24,550 ‫fungsi ini, kita akan melewati cap waktu JWT. 416 00:20:24,550 --> 00:20:27,530 ‫Jadi pada dasarnya, stempel waktu yang 417 00:20:27,530 --> 00:20:29,630 ‫mengatakan kapan token dikeluarkan. 418 00:20:29,630 --> 00:20:32,190 ‫Jadi sebut saja JWTTimestamp. 419 00:20:32,190 --> 00:20:34,437 ‫Baiklah. 420 00:20:40,310 --> 00:20:41,143 ‫Dan secara default, kami akan mengembalikan false dari metode ini. 421 00:20:41,143 --> 00:20:44,600 ‫Dan itu berarti bahwa pengguna tidak 422 00:20:44,600 --> 00:20:45,720 ‫mengubah 423 00:20:45,720 --> 00:20:48,320 ‫kata sandinya setelah token dikeluarkan. 424 00:20:48,320 --> 00:20:50,410 ‫Oke? 425 00:20:50,410 --> 00:20:51,860 ‫Jadi mari kita taruh di sini, kembalikan false, pada dasarnya secara default. 426 00:20:51,860 --> 00:20:56,860 ‫Oke. 427 00:20:58,470 --> 00:20:59,303 ‫Tapi kemudian, 428 00:20:59,303 --> 00:21:02,987 ‫kami juga memiliki jika ini, dan ingat bahwa dalam metode instan, kata 429 00:21:02,987 --> 00:21:05,827 ‫kunci this selalu menunjuk ke dokumen saat ini. 430 00:21:05,827 --> 00:21:09,477 ‫Dan karena itu, di sini kita memiliki akses ke properti. 431 00:21:09,477 --> 00:21:13,210 ‫Sekarang, kita sebenarnya perlu membuat bidang sekarang dalam skema kita 432 00:21:13,210 --> 00:21:16,280 ‫untuk tanggal di mana kata sandi telah diubah. 433 00:21:16,280 --> 00:21:18,750 ‫Jadi kita belum punya itu. 434 00:21:18,750 --> 00:21:20,050 ‫Jadi mari kita cepat menambahkannya di sini. 435 00:21:21,200 --> 00:21:23,713 ‫Jadi passwordChangedAt, dan tipenya 436 00:21:25,980 --> 00:21:27,813 ‫adalah Date. 437 00:21:31,320 --> 00:21:34,520 ‫Sekarang, properti passwordChangedAt di sini akan 438 00:21:34,520 --> 00:21:37,890 ‫selalu berubah, tentu saja, ketika seseorang 439 00:21:37,890 --> 00:21:40,160 ‫mengubah kata sandi. 440 00:21:40,160 --> 00:21:42,910 ‫Jadi saat ini, kita tidak memiliki logika itu di mana pun, 441 00:21:42,910 --> 00:21:45,270 ‫dan tidak ada tempat kita benar-benar mendefinisikan properti ini. 442 00:21:45,270 --> 00:21:48,743 ‫Jadi, sebagian besar dokumen, jadi sebagian 443 00:21:49,630 --> 00:21:53,230 ‫besar pengguna, mereka tidak akan memiliki properti ini 444 00:21:53,230 --> 00:21:56,720 ‫di data mereka, jadi di objek mereka, bukan? 445 00:21:56,720 --> 00:21:58,600 ‫Jadi, tentu saja, kita perlu mengujinya. 446 00:21:58,600 --> 00:22:01,363 ‫Oke? 447 00:22:03,430 --> 00:22:04,610 ‫Jadi jika properti 448 00:22:04,610 --> 00:22:07,740 ‫passwordChangedAt ada, baru kita ingin benar-benar melakukan perbandingan. 449 00:22:07,740 --> 00:22:11,510 ‫Oke? 450 00:22:11,510 --> 00:22:12,343 ‫Tetapi jika 451 00:22:12,343 --> 00:22:16,010 ‫tidak, jadi jika passwordChanged tidak ada, maka itu berarti bahwa pengguna tidak 452 00:22:16,010 --> 00:22:17,640 ‫pernah benar-benar mengubah password, dan 453 00:22:17,640 --> 00:22:20,020 ‫oleh karena itu kita dapat mengembalikan false. 454 00:22:20,020 --> 00:22:23,171 ‫Jadi sekali lagi, itu default kami, artinya 455 00:22:23,171 --> 00:22:25,560 ‫pengguna tidak mengubah kata 456 00:22:25,560 --> 00:22:28,190 ‫sandi setelah stempel waktu ini. 457 00:22:28,190 --> 00:22:30,540 ‫Oke. 458 00:22:30,540 --> 00:22:31,373 ‫Dan 459 00:22:31,373 --> 00:22:35,760 ‫sekarang, untuk memulai, mari kita benar-benar masuk ke konsol ini. passwordChangedAt, dan tentu saja, JWTTimestamp juga, supaya kita 460 00:22:35,760 --> 00:22:37,933 ‫bisa 461 00:22:39,370 --> 00:22:42,010 ‫melihat bagaimana kita bisa membandingkannya. 462 00:22:42,010 --> 00:22:44,950 ‫Baiklah. 463 00:22:44,950 --> 00:22:45,783 ‫Dan sekarang kita 464 00:22:47,560 --> 00:22:49,690 ‫harus benar-benar membuat pengguna yang memiliki properti ini, oke? 465 00:22:49,690 --> 00:22:52,720 ‫Dan lagi, nanti di bagian saat kita akan menerapkan 466 00:22:52,720 --> 00:22:54,260 ‫logika untuk mengubah kata 467 00:22:54,260 --> 00:22:57,280 ‫sandi adalah saat kita akan menyetel properti ini. 468 00:22:57,280 --> 00:22:59,760 ‫Oke? 469 00:22:59,760 --> 00:23:00,593 ‫Tapi sekarang kita 470 00:23:00,593 --> 00:23:04,140 ‫akan secara artifisial, pada dasarnya, mengaturnya di sini ketika kita membuat pengguna baru. 471 00:23:04,140 --> 00:23:06,260 ‫Oke? 472 00:23:06,260 --> 00:23:07,093 ‫Jadi mari kita taruh di sini. 473 00:23:08,690 --> 00:23:10,130 ‫Dan di sini, tanggal berapa pun, sebenarnya, akan ditayangkan. 474 00:23:10,130 --> 00:23:12,810 ‫Jadi katakanlah 30 April 2019 di sini. 475 00:23:12,810 --> 00:23:17,810 ‫Dan itu kemudian harus diuraikan ke dalam MongoDB dengan baik. 476 00:23:18,430 --> 00:23:21,313 ‫Mari kita coba itu, lihat apakah itu berhasil. 477 00:23:22,460 --> 00:23:24,293 ‫Dan itu tidak berhasil. 478 00:23:25,210 --> 00:23:26,520 ‫Jadi itu tidak bisa benar-benar mengurai tanggal, katakanlah. 479 00:23:26,520 --> 00:23:29,913 ‫Dan sebenarnya, saya harus memulai dengan tahun 480 00:23:30,980 --> 00:23:33,710 ‫dan kemudian hari di akhir. 481 00:23:33,710 --> 00:23:36,400 ‫Jadi 2019 dan kemudian 30 April. 482 00:23:36,400 --> 00:23:41,050 ‫Coba itu lagi. 483 00:23:41,050 --> 00:23:42,103 ‫Dan Anda melihat bahwa sekarang ini benar-benar bekerja. 484 00:23:43,190 --> 00:23:45,300 ‫Jadi kami memiliki tanggal yang diuraikan di sini. 485 00:23:45,300 --> 00:23:48,210 ‫Oke? 486 00:23:48,210 --> 00:23:49,350 ‫Sekarang, untuk benar-benar melihat 487 00:23:49,350 --> 00:23:51,910 ‫hasil ini, tentu saja kita perlu memanggil metode ini. 488 00:23:51,910 --> 00:23:55,040 ‫Oke? 489 00:23:55,040 --> 00:23:56,560 ‫Jadi itulah yang akan kita lakukan di langkah keempat. 490 00:23:56,560 --> 00:23:59,033 ‫Oke? 491 00:24:00,010 --> 00:24:01,110 ‫Jadi, ingatlah 492 00:24:01,110 --> 00:24:04,630 ‫bahwa kita dapat memanggil metode instance ini pada dokumen pengguna. 493 00:24:04,630 --> 00:24:06,200 ‫Jadi pengguna segar. changePasswordAfter, dan kemudian cap 494 00:24:06,200 --> 00:24:09,197 ‫waktu itu. 495 00:24:14,837 --> 00:24:17,370 ‫Jadi itu di diterjemahkan. iat, jadi dikeluarkan pada, pada dasarnya. 496 00:24:17,370 --> 00:24:22,370 ‫Baiklah. 497 00:24:25,450 --> 00:24:26,350 ‫Jadi mari kita lihat saja hasil dari melakukan itu. 498 00:24:26,350 --> 00:24:29,130 ‫Jadi, tentu saja, ini seharusnya sekarang, bukan 499 00:24:29,130 --> 00:24:32,953 ‫di sini, jadi ini sekarang harus masuk ke konsol dua nilai ini. 500 00:24:33,870 --> 00:24:37,123 ‫Oke. 501 00:24:39,320 --> 00:24:40,153 ‫Sekarang, tentu 502 00:24:40,153 --> 00:24:43,170 ‫saja saya harus masuk dengan pengguna ini, jadi dengan tes, 503 00:24:43,170 --> 00:24:44,223 ‫jadi ini dia. 504 00:24:47,780 --> 00:24:48,853 ‫Gabung. 505 00:24:50,250 --> 00:24:51,173 ‫Salin token ini di sini lagi. 506 00:24:53,090 --> 00:24:56,200 ‫Dan lagi, pada dasarnya 507 00:24:56,200 --> 00:24:59,580 ‫kita akan mengotomatiskannya di video berikutnya. 508 00:24:59,580 --> 00:25:01,233 ‫Oke. 509 00:25:02,740 --> 00:25:03,700 ‫Tempelkan di sini. 510 00:25:03,700 --> 00:25:04,673 ‫Dan sekarang, kami benar-benar mendapatkan bug ini di sini. 511 00:25:05,670 --> 00:25:08,312 ‫Jadi saya hanya salah mengeja nama fungsi ini di sini. 512 00:25:08,312 --> 00:25:13,312 ‫Nah, mari kita salin saja. 513 00:25:13,670 --> 00:25:14,920 ‫Coba lagi. 514 00:25:16,410 --> 00:25:17,403 ‫Oh man. 515 00:25:18,780 --> 00:25:20,150 ‫Apa yang salah sekarang? 516 00:25:20,150 --> 00:25:21,823 ‫Dan sepertinya saya lupa log ini di sini. 517 00:25:25,420 --> 00:25:27,633 ‫Jadi kesalahan bodoh lainnya. 518 00:25:28,752 --> 00:25:30,090 ‫Mungkin melihat yang datang. 519 00:25:30,090 --> 00:25:32,320 ‫Tapi sekarang di sini kita pergi. 520 00:25:32,320 --> 00:25:33,550 ‫Jadi semuanya bekerja 521 00:25:33,550 --> 00:25:35,120 ‫dengan baik, dan yang benar-benar ingin 522 00:25:35,120 --> 00:25:37,450 ‫kami lihat saat ini adalah dua hasil ini. 523 00:25:37,450 --> 00:25:39,560 ‫Jadi pada dasarnya kita memiliki yang ini di 524 00:25:39,560 --> 00:25:43,110 ‫sini dalam format tanggal ini, dan kemudian yang lainnya dalam stempel waktu milidetik atau kedua 525 00:25:43,110 --> 00:25:43,943 ‫ini di sini. 526 00:25:43,943 --> 00:25:47,600 ‫Jadi, sekarang kita perlu mengonversi passwordChangedAt 527 00:25:47,600 --> 00:25:51,670 ‫ini juga menjadi stempel waktu seperti itu. 528 00:25:51,670 --> 00:25:54,240 ‫Baiklah? 529 00:25:54,240 --> 00:25:55,073 ‫Jadi, untuk itu, mari buat variabel baru. 530 00:25:55,073 --> 00:25:57,853 ‫Jadi berubah Timestamp. 531 00:25:59,560 --> 00:26:01,330 ‫Dan kita bisa menggunakan ini. kata sandiDiubahPada. dapatkanWaktu. 532 00:26:03,800 --> 00:26:06,100 ‫Oke? 533 00:26:12,730 --> 00:26:13,563 ‫Jadi, itulah 534 00:26:13,563 --> 00:26:16,913 ‫salah satu dari sekian banyak fungsi tanggal yang diberikan JavaScript kepada kita. 535 00:26:16,913 --> 00:26:18,563 ‫Baiklah. 536 00:26:19,450 --> 00:26:20,960 ‫Dan sekarang, mari kita 537 00:26:20,960 --> 00:26:23,760 ‫cepat membandingkan keduanya karena sebenarnya kita belum cukup siap. 538 00:26:23,760 --> 00:26:26,253 ‫Jadi mengirimkannya hanya untuk melihat hasilnya di sini. 539 00:26:28,770 --> 00:26:31,930 ‫Jadi apa yang kita lihat di sini pada dasarnya adalah 540 00:26:31,930 --> 00:26:33,610 ‫bahwa yang ini sekarang, pada 541 00:26:33,610 --> 00:26:36,580 ‫dasarnya, dalam hitungan detik, dan yang ini dalam milidetik. 542 00:26:36,580 --> 00:26:38,210 ‫Jadi 1000 kali lebih banyak. 543 00:26:38,210 --> 00:26:40,540 ‫Jadi, kita tahu kita perlu membaginya 544 00:26:40,540 --> 00:26:43,340 ‫dengan 1000 dan kemudian mengurai semuanya sebagai bilangan bulat. 545 00:26:45,630 --> 00:26:48,583 ‫Dan untuk itu, kami menggunakan parseInt. 546 00:26:50,550 --> 00:26:52,820 ‫Jadi fungsi JavaScript lain yang tersedia untuk angka. 547 00:26:52,820 --> 00:26:57,180 ‫Dan kemudian kita sebenarnya juga perlu menentukan dasarnya. 548 00:26:57,180 --> 00:27:00,320 ‫Jadi ini adalah bilangan basis 10. 549 00:27:00,320 --> 00:27:02,920 ‫Baiklah? 550 00:27:02,920 --> 00:27:03,970 ‫Dan sekarang, mari kita lihat lagi hasilnya. 551 00:27:03,970 --> 00:27:07,373 ‫Dan sekarang, itu terlihat jauh lebih ramah. 552 00:27:10,120 --> 00:27:13,360 ‫Oke. 553 00:27:13,360 --> 00:27:14,193 ‫Jadi, sekarang mari kita kembalikan hasil kita. 554 00:27:14,193 --> 00:27:17,040 ‫Dan sekali lagi, perlu diingat bahwa false berarti tidak berubah. 555 00:27:17,040 --> 00:27:22,040 ‫Oke? 556 00:27:24,500 --> 00:27:25,520 ‫Dan tidak 557 00:27:25,520 --> 00:27:30,207 ‫diubah pada dasarnya berarti bahwa hari atau waktu saat token dikeluarkan kurang 558 00:27:32,300 --> 00:27:34,240 ‫dari stempel waktu yang diubah. 559 00:27:34,240 --> 00:27:37,893 ‫Oke? 560 00:27:40,280 --> 00:27:41,113 ‫Jadi sebagai contoh 561 00:27:44,330 --> 00:27:45,830 ‫di sini, katakanlah token dikeluarkan pada waktu 100. 562 00:27:45,830 --> 00:27:49,327 ‫Tapi kemudian, kami mengubah kata sandi, katakanlah, pada waktu 200. 563 00:27:50,460 --> 00:27:53,843 ‫Oke? 564 00:27:55,240 --> 00:27:56,073 ‫Jadi, kami 565 00:27:56,073 --> 00:27:57,609 ‫mengubah kata sandi setelah token 566 00:27:57,609 --> 00:27:59,840 ‫dikeluarkan, dan oleh karena itu, ini sekarang benar. 567 00:27:59,840 --> 00:28:01,940 ‫Baiklah? 568 00:28:01,940 --> 00:28:03,379 ‫Dan itulah tepatnya yang ingin kami kembalikan 569 00:28:03,379 --> 00:28:04,810 ‫di sini, karena false berarti 570 00:28:04,810 --> 00:28:06,910 ‫tidak berubah, dan jadi true, tentu saja, berarti berubah. 571 00:28:06,910 --> 00:28:09,200 ‫Dan, itulah yang kita miliki di sini. 572 00:28:09,200 --> 00:28:11,980 ‫Tapi sekarang, katakanlah kata sandi terakhir 573 00:28:11,980 --> 00:28:13,410 ‫diubah pada 574 00:28:13,410 --> 00:28:15,810 ‫200, tetapi hanya setelah itu, kami 575 00:28:15,810 --> 00:28:18,640 ‫mengeluarkan token, jadi katakanlah, pada waktu 300. 576 00:28:18,640 --> 00:28:21,260 ‫Jadi, 300, kurang dari 200? 577 00:28:21,260 --> 00:28:23,660 ‫Tidak, itu salah. 578 00:28:23,660 --> 00:28:25,160 ‫Jadi, kami mengembalikan false, yang sekali lagi berarti tidak berubah. 579 00:28:25,160 --> 00:28:29,200 ‫Jadi, itulah mengapa kami menggunakan tanda less ini di sini. 580 00:28:29,200 --> 00:28:32,720 ‫Oke? 581 00:28:32,720 --> 00:28:33,553 ‫Mari kita kembali ke controller kita dan benar-benar menggunakan ini. 582 00:28:36,800 --> 00:28:41,800 ‫Jadi kalau passwordnya benar-benar diubah, nah, dalam hal 583 00:28:45,480 --> 00:28:49,910 ‫ini sebenarnya kita menginginkan sebuah kesalahan. 584 00:28:49,910 --> 00:28:53,030 ‫Jadi kembali berikutnya, sekali lagi, AppError baru. 585 00:28:53,030 --> 00:28:57,623 ‫Baru-baru ini... 586 00:29:02,970 --> 00:29:04,220 ‫Silakan masuk lagi. 587 00:29:11,790 --> 00:29:13,620 ‫Oke. 588 00:29:13,620 --> 00:29:15,030 ‫Dan sekali lagi, kode 401. 589 00:29:15,030 --> 00:29:18,363 ‫Baiklah. 590 00:29:19,770 --> 00:29:20,820 ‫Jadi sekali lagi, 591 00:29:20,820 --> 00:29:23,220 ‫ini akan mengembalikan true jika pengguna benar-benar mengubah kata sandinya. 592 00:29:23,220 --> 00:29:25,790 ‫Jadi, jika semua ini benar, 593 00:29:25,790 --> 00:29:28,540 ‫ya, maka dalam kasus itulah kita 594 00:29:28,540 --> 00:29:30,600 ‫ingin kesalahan ini terjadi. 595 00:29:30,600 --> 00:29:33,220 ‫Baiklah? 596 00:29:33,220 --> 00:29:34,820 ‫Jadi itu sebenarnya langkah terakhir. 597 00:29:34,820 --> 00:29:37,510 ‫Oke. 598 00:29:37,510 --> 00:29:38,952 ‫Jadi pada dasarnya, jika kode dapat membuat 599 00:29:38,952 --> 00:29:41,030 ‫semuanya sampai akhir kode ini di sini, baru kemudian, selanjutnya akan dieksekusi. 600 00:29:41,030 --> 00:29:45,410 ‫Dan kemudian, dengan berikutnya, kita pergi ke pengendali rute 601 00:29:45,410 --> 00:29:49,100 ‫berikutnya, yang secara efektif berarti memberikan akses ke 602 00:29:49,100 --> 00:29:51,470 ‫rute yang dilindungi itu. 603 00:29:51,470 --> 00:29:52,783 ‫Mari kita benar-benar menempatkan bahwa di sini. 604 00:29:53,750 --> 00:29:55,740 ‫Berikan akses ke rute yang dilindungi. 605 00:29:55,740 --> 00:30:00,740 ‫Oke? 606 00:30:02,340 --> 00:30:03,597 ‫Karena itulah yang benar-benar dilakukan selanjutnya. 607 00:30:03,597 --> 00:30:05,310 ‫Selanjutnya membawa kita ke 608 00:30:05,310 --> 00:30:08,070 ‫middleware berikutnya, yang biasanya, kemudian, pengendali rute itu 609 00:30:08,070 --> 00:30:10,880 ‫sendiri, jadi yang mengirim kembali data yang dilindungi. 610 00:30:10,880 --> 00:30:14,550 ‫Oke. 611 00:30:14,550 --> 00:30:15,383 ‫Hanya satu hal 612 00:30:15,383 --> 00:30:18,540 ‫terakhir yang ingin kami lakukan di sini adalah memasukkan seluruh data pengguna pada permintaan. 613 00:30:18,540 --> 00:30:22,930 ‫Jadi kita cukup mengatakan, req, so request, . pengguna akan sama dengan pengguna 614 00:30:22,930 --> 00:30:27,100 ‫baru. 615 00:30:27,100 --> 00:30:30,510 ‫Oke. 616 00:30:30,510 --> 00:30:31,343 ‫Dan sekali 617 00:30:31,343 --> 00:30:32,430 ‫lagi, tentu saja, 618 00:30:32,430 --> 00:30:34,930 ‫kode hanya mencapai titik ini jika semuanya benar. 619 00:30:34,930 --> 00:30:37,470 ‫Oke? 620 00:30:37,470 --> 00:30:38,303 ‫Jadi, ini di 621 00:30:38,303 --> 00:30:40,710 ‫sini mungkin berguna di beberapa titik di masa depan. 622 00:30:40,710 --> 00:30:42,110 ‫Besar. 623 00:30:43,150 --> 00:30:43,983 ‫Mari kita uji ini sekali lagi. 624 00:30:43,983 --> 00:30:46,450 ‫Dan pada dasarnya, perubahan ini di masa lalu sekarang. 625 00:30:46,450 --> 00:30:51,450 ‫Jadi, token yang kita miliki di sini, atau sebenarnya, saya 626 00:30:51,820 --> 00:30:53,840 ‫dapat menggunakan kembali 627 00:30:53,840 --> 00:30:56,890 ‫token ini saja daripada mencatatnya lagi. 628 00:30:56,890 --> 00:30:58,520 ‫Tapi bagaimanapun, token ini 629 00:30:58,520 --> 00:31:00,500 ‫dikeluarkan setelah kata sandi diubah. 630 00:31:00,500 --> 00:31:02,344 ‫Jadi, token ini sekarang harus berfungsi. 631 00:31:02,344 --> 00:31:04,920 ‫Jadi mari kita benar-benar masuk 632 00:31:04,920 --> 00:31:07,500 ‫lagi dan mencobanya dengan token ini. 633 00:31:10,900 --> 00:31:13,203 ‫Dan memang, kami mendapatkan akses. 634 00:31:18,020 --> 00:31:20,030 ‫Sekarang, pindah ke Kompas untuk mengubah tanggal itu. 635 00:31:20,030 --> 00:31:22,853 ‫Oke. 636 00:31:24,511 --> 00:31:26,010 ‫Mari kita taruh satu bulan kemudian. 637 00:31:26,010 --> 00:31:27,657 ‫Jadi, itu sebenarnya akan terjadi di 638 00:31:27,657 --> 00:31:30,780 ‫masa depan, jadi setidaknya, di masa depan saya ketika saya merekam video ini. 639 00:31:30,780 --> 00:31:34,150 ‫Tentu saja, Anda akan melakukan ini di lain waktu. 640 00:31:34,150 --> 00:31:36,640 ‫Jadi, untuk menguji ini, harap letakkan ini di masa depan Anda. 641 00:31:36,640 --> 00:31:40,373 ‫Jadi di masa depan tanggal di mana Anda 642 00:31:41,420 --> 00:31:43,060 ‫menonton video ini. 643 00:31:43,060 --> 00:31:44,710 ‫Jadi kalau saya 644 00:31:45,960 --> 00:31:50,960 ‫sekarang kembali ke Postman dan login lagi, oke, jadi kalau saya login 645 00:31:53,860 --> 00:31:56,430 ‫lagi sekarang dan mencoba mengakses rute 646 00:31:56,430 --> 00:31:58,710 ‫itu, nah, token ini akan 647 00:31:58,710 --> 00:32:01,420 ‫dikeluarkan, pada dasarnya, setelah kata sandi diubah. 648 00:32:01,420 --> 00:32:03,553 ‫Atau sebenarnya sebelum password diubah. 649 00:32:08,680 --> 00:32:10,590 ‫Jadi, maaf atas kebingungan itu. 650 00:32:10,590 --> 00:32:12,610 ‫Jadi kata sandi diubah pada 30 651 00:32:12,610 --> 00:32:15,800 ‫Mei, tetapi token ini dikeluarkan pada tanggal 2 Mei, dan sebelumnya. 652 00:32:15,800 --> 00:32:19,650 ‫Jadi pada dasarnya, sekarang seolah-olah pengguna telah mengubah kata 653 00:32:19,650 --> 00:32:21,950 ‫sandi mereka setelah token dikeluarkan. 654 00:32:21,950 --> 00:32:25,880 ‫Jadi, itulah situasi di mana kami tidak ingin memberikan akses ke 655 00:32:25,880 --> 00:32:27,341 ‫rute yang dilindungi. 656 00:32:27,341 --> 00:32:31,070 ‫Jadi, ini sekarang harus mencerminkan itu. 657 00:32:31,070 --> 00:32:35,170 ‫Dan memang, pengguna baru saja mengubah 658 00:32:35,170 --> 00:32:38,740 ‫kata sandi, silakan masuk lagi. 659 00:32:38,740 --> 00:32:40,280 ‫Besar. 660 00:32:40,280 --> 00:32:41,240 ‫Jadi itu sekarang berfungsi. 661 00:32:41,240 --> 00:32:42,953 ‫Jadi middleware pelindung kami sekarang sepenuhnya diimplementasikan. 662 00:32:43,870 --> 00:32:48,000 ‫Mari kita singkirkan konsol ini. masuk di sini. 663 00:32:48,000 --> 00:32:51,620 ‫Tidak perlu yang itu lagi. 664 00:32:51,620 --> 00:32:53,820 ‫Dan oke. 665 00:32:53,820 --> 00:32:55,800 ‫Jadi mari kita rekap dengan cepat, dan 666 00:32:55,800 --> 00:32:57,230 ‫video ini berjalan sangat 667 00:32:57,230 --> 00:32:59,520 ‫lama, sedikit lebih lama dari yang saya harapkan. 668 00:32:59,520 --> 00:33:01,330 ‫Tetapi sangat penting 669 00:33:01,330 --> 00:33:03,820 ‫untuk memahami dan menjelaskan bagaimana 670 00:33:03,820 --> 00:33:06,700 ‫semua ini bekerja dan mengapa ini penting. 671 00:33:06,700 --> 00:33:07,810 ‫Jadi, saya lebih suka itu daripada membuat video ini jauh lebih pendek. 672 00:33:07,810 --> 00:33:12,710 ‫Tentu saja, saya hanya bisa menulis kodenya, tetapi Anda tidak akan benar-benar mengerti apa 673 00:33:12,710 --> 00:33:14,127 ‫yang sedang terjadi. 674 00:33:14,127 --> 00:33:17,330 ‫Jadi bagian ini sudah kita pahami. 675 00:33:17,330 --> 00:33:19,410 ‫Kemudian bagian ini, saya percaya 676 00:33:19,410 --> 00:33:21,680 ‫juga, jadi di sinilah verifikasi terjadi, 677 00:33:21,680 --> 00:33:24,060 ‫jadi pada dasarnya melihat apakah muatan token 678 00:33:24,060 --> 00:33:26,570 ‫belum dimanipulasi oleh beberapa pihak ketiga yang jahat. 679 00:33:26,570 --> 00:33:30,900 ‫Oke? 680 00:33:30,900 --> 00:33:31,733 ‫Dan karena kami 681 00:33:31,733 --> 00:33:33,730 ‫kemudian mencapai kode ini di sini, itu berarti tidak 682 00:33:33,730 --> 00:33:36,790 ‫ada yang mengubah token web JSON, dan oleh karena itu, kami bisa mendapatkan pengguna baru. 683 00:33:36,790 --> 00:33:39,350 ‫Jadi pada dasarnya, kita bisa mendapatkan pengguna saat 684 00:33:39,350 --> 00:33:41,690 ‫ini, sebut saja pengguna saat ini. 685 00:33:41,690 --> 00:33:43,650 ‫Mengapa tidak? 686 00:33:43,650 --> 00:33:44,483 ‫Jadi di sini, di sini, dan juga di sini. 687 00:33:45,450 --> 00:33:47,993 ‫Oke? 688 00:33:49,670 --> 00:33:50,503 ‫Jadi kita bisa 689 00:33:50,503 --> 00:33:53,020 ‫mendapatkan currentUser dari ID yang baru saja di-decode dari payload. 690 00:33:53,020 --> 00:33:55,023 ‫Sekarang, jika pengguna saat ini tidak 691 00:33:56,100 --> 00:33:58,260 ‫ada, jadi inilah yang kami uji di 692 00:33:58,260 --> 00:34:00,660 ‫sini, maka dalam hal ini kami tidak ingin 693 00:34:00,660 --> 00:34:01,990 ‫memberikan akses ke 694 00:34:01,990 --> 00:34:04,290 ‫rute, dan malah membuat kesalahan baru ini. 695 00:34:04,290 --> 00:34:06,343 ‫Tapi kalau usernya memang ada, 696 00:34:07,400 --> 00:34:08,870 ‫nah, kita lanjut 697 00:34:08,870 --> 00:34:12,030 ‫ke poin nomor empat, dimana kemudian kita cek 698 00:34:12,030 --> 00:34:15,060 ‫apakah ada perubahan password setelah token dikeluarkan, kan? 699 00:34:15,060 --> 00:34:18,060 ‫Dan jika ya, sekali lagi, kami membuat kesalahan baru. 700 00:34:18,060 --> 00:34:21,200 ‫Dan jika tidak, maka kami membuatnya sampai ke 701 00:34:21,200 --> 00:34:22,720 ‫akhir fungsi middleware, 702 00:34:22,720 --> 00:34:24,460 ‫di mana kami kemudian 703 00:34:24,460 --> 00:34:26,750 ‫menetapkan pengguna saat ini untuk meminta. pengguna sehingga kami kemudian dapat menggunakannya 704 00:34:26,750 --> 00:34:30,640 ‫dalam fungsi middleware berikutnya. 705 00:34:30,640 --> 00:34:33,860 ‫Oke? 706 00:34:33,860 --> 00:34:34,693 ‫Karena ingat, 707 00:34:34,693 --> 00:34:37,030 ‫objek permintaan ini, ini adalah objek yang bergerak, 708 00:34:37,030 --> 00:34:38,950 ‫pada dasarnya, dari middleware ke middleware. 709 00:34:38,950 --> 00:34:40,660 ‫Jadi, jika kita ingin meneruskan data 710 00:34:40,660 --> 00:34:42,330 ‫dari satu middleware ke middleware 711 00:34:42,330 --> 00:34:44,600 ‫berikutnya, maka kita cukup meletakkan beberapa hal pada 712 00:34:44,600 --> 00:34:47,860 ‫objek request, dan kemudian data itu akan tersedia di lain waktu. 713 00:34:47,860 --> 00:34:51,220 ‫Baiklah. 714 00:34:51,220 --> 00:34:52,053 ‫Jadi, itu saja. 715 00:34:52,053 --> 00:34:52,886 ‫Ini adalah 716 00:34:52,886 --> 00:34:54,560 ‫algoritma perlindungan rute yang sangat 717 00:34:54,560 --> 00:34:58,300 ‫canggih dan sangat lengkap, pada dasarnya, tetapi saya pikir sangat penting 718 00:34:58,300 --> 00:34:59,740 ‫untuk melakukannya sebaik mungkin. 719 00:34:59,740 --> 00:35:02,820 ‫Bagaimanapun, senang melihat Anda berhasil sampai di akhir 720 00:35:02,820 --> 00:35:04,990 ‫video besar ini, dan sampai 721 00:35:04,990 --> 00:35:07,050 ‫jumpa di video berikutnya.