1 00:00:01,210 --> 00:00:04,650 ‫Instruktur: Dan sekarang mari kita akhirnya membuat bagian terakhir 2 00:00:04,650 --> 00:00:07,010 ‫dari Fungsi Pengaturan Ulang Kata Sandi, 3 00:00:07,010 --> 00:00:10,593 ‫di mana kita sebenarnya mengatur kata sandi baru untuk pengguna. 4 00:00:12,250 --> 00:00:15,900 ‫Jadi, seperti sebelumnya, mari kita mulai dengan mendefinisikan 5 00:00:15,900 --> 00:00:19,713 ‫langkah-langkah yang akan kita ambil untuk alur resetPassword ini. 6 00:00:21,240 --> 00:00:26,240 ‫Jadi, pertama-tama, dapatkan pengguna berdasarkan token. 7 00:00:30,350 --> 00:00:35,350 ‫Kemudian sebagai langkah kedua, kami akan mengatur kata sandi 8 00:00:35,890 --> 00:00:40,153 ‫baru tetapi hanya jika token belum kedaluwarsa, 9 00:00:42,070 --> 00:00:44,040 ‫dan ada pengguna. 10 00:00:44,040 --> 00:00:48,633 ‫Jadi dalam hal ini, atur kata sandi baru. 11 00:00:51,580 --> 00:00:55,250 ‫Kemudian setelah itu, kita perlu memperbarui 12 00:00:57,210 --> 00:01:01,000 ‫properti ChangePasswordAt untuk pengguna saat ini, dan 13 00:01:04,080 --> 00:01:05,403 ‫terakhir, seperti 14 00:01:07,320 --> 00:01:10,533 ‫biasa dalam fungsi ini, adalah memasukkan 15 00:01:11,680 --> 00:01:12,853 ‫pengguna. 16 00:01:14,010 --> 00:01:18,840 ‫Pada dasarnya, kirim Token Web JSON ke klien. 17 00:01:18,840 --> 00:01:22,733 ‫Oke, begitu banyak pekerjaan yang harus dilakukan, jadi mari kita mulai. 18 00:01:23,950 --> 00:01:27,493 ‫Jadi, ingat dari video terakhir, bahwa token reset 19 00:01:27,493 --> 00:01:30,450 ‫yang sebenarnya dikirim di URL adalah token 20 00:01:30,450 --> 00:01:33,110 ‫yang tidak dienkripsi di sini. 21 00:01:33,110 --> 00:01:34,723 ‫Jadi, sebenarnya yang ini. 22 00:01:35,570 --> 00:01:37,810 ‫Tapi yang kita punya di 23 00:01:37,810 --> 00:01:39,680 ‫database adalah yang terenkripsi. 24 00:01:39,680 --> 00:01:42,580 ‫Jadi kita sudah membicarakannya sebelumnya, dan sekarang yang 25 00:01:42,580 --> 00:01:44,910 ‫perlu kita lakukan, pada dasarnya adalah 26 00:01:44,910 --> 00:01:46,630 ‫mengenkripsi token asli 27 00:01:46,630 --> 00:01:49,240 ‫lagi, jadi kita bisa membandingkannya dengan yang 28 00:01:49,240 --> 00:01:51,433 ‫disimpan, jadi yang terenkripsi di database. 29 00:01:52,870 --> 00:01:55,110 ‫Jadi, kami sebenarnya melakukan sesuatu yang serupa 30 00:01:55,110 --> 00:01:57,890 ‫sebelumnya dengan kata sandi, tetapi dengan kata sandi, kami 31 00:01:57,890 --> 00:02:01,010 ‫tidak dapat membandingkannya semudah yang kami bisa dengan yang ini, 32 00:02:01,010 --> 00:02:02,650 ‫sekali lagi karena untuk 33 00:02:02,650 --> 00:02:05,770 ‫kata sandi kami menggunakan algoritma bcrypt yang cukup rumit, yang 34 00:02:05,770 --> 00:02:07,490 ‫dalam hal ini, kami tidak. 35 00:02:07,490 --> 00:02:09,750 ‫Jadi, di sini sangat mudah. 36 00:02:09,750 --> 00:02:13,040 ‫Yang perlu kita lakukan lagi, adalah 37 00:02:13,040 --> 00:02:17,390 ‫mengenkripsi token dan membandingkannya dengan yang terenkripsi di database. 38 00:02:17,390 --> 00:02:22,390 ‫Jadi, katakanlah hashedToken, jadi kita sekarang akan benar-benar membutuhkan 39 00:02:23,670 --> 00:02:26,813 ‫paket crypto di sini juga. 40 00:02:31,730 --> 00:02:36,167 ‫Const crypto dan kemudian require('crypto'). 41 00:02:41,280 --> 00:02:42,123 ‫Sekarang benar. 42 00:02:43,780 --> 00:02:47,593 ‫Kalau begitu mari kita kembali, jadi, kita 43 00:02:48,750 --> 00:02:51,610 ‫menggunakan kripto. buatHash. 44 00:02:53,070 --> 00:02:57,973 ‫Ingat, lalu nama algoritmanya lagi, sha256, 45 00:02:58,910 --> 00:03:03,910 ‫lalu . perbarui, pada dasarnya untuk tempat, untuk string 46 00:03:04,140 --> 00:03:06,040 ‫yang ingin kita hash. 47 00:03:06,040 --> 00:03:10,110 ‫Jadi, yang itu, ingat di req. param 48 00:03:10,110 --> 00:03:14,083 ‫Jadi kami kemudian menggunakan yang ini untuk waktu yang lama. token. 49 00:03:15,060 --> 00:03:17,950 ‫Dan sekali lagi, ini adalah parameter, 50 00:03:17,950 --> 00:03:22,233 ‫karena kami menentukannya di sini di URL, jadi seperti ini. 51 00:03:23,250 --> 00:03:26,470 ‫Jadi, sekarang parameter yang disebut token. 52 00:03:26,470 --> 00:03:31,470 ‫Jadi, tentu saja, ini req. param token. 53 00:03:31,804 --> 00:03:34,790 ‫Dan kemudian, akhirnya, kita juga perlu mengatakan mencerna 54 00:03:36,840 --> 00:03:38,633 ‫dan mengubahnya menjadi heksadesimal. 55 00:03:40,380 --> 00:03:42,760 ‫Sekarang ini pada dasarnya sama seperti yang 56 00:03:42,760 --> 00:03:46,180 ‫kita miliki sebelumnya, di mana kita mengenkripsi yang asli, dan 57 00:03:46,180 --> 00:03:49,520 ‫jadi kita bisa refactor ini menjadi fungsinya sendiri, tapi mari 58 00:03:49,520 --> 00:03:51,693 ‫kita buat sederhana di sini. 59 00:03:54,240 --> 00:03:58,930 ‫Jadi, sekarang mari kita benar-benar mendapatkan pengguna berdasarkan token ini. 60 00:03:58,930 --> 00:04:01,060 ‫Karena hanya itu yang 61 00:04:01,060 --> 00:04:03,530 ‫kami ketahui tentang pengguna saat ini. 62 00:04:03,530 --> 00:04:07,080 ‫Kami tidak memiliki email, kami tidak memiliki apa-apa, jadi token 63 00:04:07,080 --> 00:04:10,130 ‫ini adalah satu-satunya yang dapat mengidentifikasi pengguna. 64 00:04:10,130 --> 00:04:12,520 ‫Jadi sekarang kita bisa, pada dasarnya, menanyakan 65 00:04:12,520 --> 00:04:14,170 ‫database untuk token ini. 66 00:04:14,170 --> 00:04:17,303 ‫Dan kemudian akan menemukan pengguna yang memiliki token ini. 67 00:04:19,230 --> 00:04:24,230 ‫Jadi, tunggu, seperti yang sudah kita ketahui, dan kemudian Pengguna. temukanSatu. 68 00:04:27,790 --> 00:04:31,213 ‫Jadi, properti itu disebut 69 00:04:32,090 --> 00:04:36,117 ‫passwordResetToken dan kami mencari hashedToken. 70 00:04:37,940 --> 00:04:42,220 ‫Dan sekarang tentu saja, kita perlu mendeklarasikannya sebagai async dan 71 00:04:43,150 --> 00:04:44,643 ‫menyiapkannya ke catchAsync. 72 00:04:48,557 --> 00:04:51,810 ‫Berikan simpanan, yang seharusnya memperbaiki bug ini, 73 00:04:51,810 --> 00:04:53,950 ‫dan memang benar. 74 00:04:53,950 --> 00:04:56,950 ‫Jadi, ini akan menemukan pengguna yang memiliki token 75 00:04:56,950 --> 00:04:59,100 ‫yang akan dikirim melalui URL. 76 00:04:59,100 --> 00:05:00,910 ‫Namun, saat ini, 77 00:05:00,910 --> 00:05:04,090 ‫kami tidak mempertimbangkan tanggal kedaluwarsa token. 78 00:05:04,090 --> 00:05:06,000 ‫Dan jadi bagaimana kita bisa melakukan itu? 79 00:05:06,000 --> 00:05:09,020 ‫Yah, pada dasarnya, yang kita inginkan 80 00:05:09,020 --> 00:05:11,860 ‫adalah memeriksa apakah properti passwordResetExpires lebih 81 00:05:11,860 --> 00:05:13,723 ‫besar dari sekarang. 82 00:05:14,890 --> 00:05:17,350 ‫Karena jika expired date lebih besar 83 00:05:17,350 --> 00:05:20,420 ‫dari sekarang, berarti masih di masa depan yang 84 00:05:20,420 --> 00:05:22,313 ‫artinya belum expired. 85 00:05:23,180 --> 00:05:24,850 ‫Jadi, itulah cara yang sangat 86 00:05:24,850 --> 00:05:28,343 ‫mudah di mana kita benar-benar dapat melakukannya dengan benar dengan kueri ini. 87 00:05:30,619 --> 00:05:32,702 ‫Jadi, passwordResetExpires, di mana tanggal 88 00:05:35,170 --> 00:05:37,460 ‫itu disimpan, dan sekarang kita hanya 89 00:05:37,460 --> 00:05:38,840 ‫perlu memeriksa 90 00:05:38,840 --> 00:05:41,470 ‫apakah tanggal itu lebih besar dari sekarang. 91 00:05:41,470 --> 00:05:45,440 ‫Jadi kita sudah tahu bagaimana melakukannya dengan MongoDB, bukan? 92 00:05:45,440 --> 00:05:50,110 ‫Jadi, objek baru dan kemudian operator yang lebih besar dan kemudian yang ingin 93 00:05:50,110 --> 00:05:53,737 ‫kita bandingkan adalah Date. sekarang, dan ini sebenarnya 94 00:05:56,310 --> 00:05:59,410 ‫akan menjadi stempel waktu sekarang, tetapi di 95 00:05:59,410 --> 00:06:02,900 ‫balik layar, MongoDB kemudian akan mengubah semuanya menjadi 96 00:06:02,900 --> 00:06:05,170 ‫sama, dan karena itu dapat membandingkannya 97 00:06:05,170 --> 00:06:06,520 ‫secara akurat. 98 00:06:08,070 --> 00:06:10,440 ‫Jadi dengan ini kita dapat, pada 99 00:06:10,440 --> 00:06:14,120 ‫saat yang sama, menemukan pengguna untuk token dan juga memeriksa 100 00:06:14,120 --> 00:06:16,370 ‫apakah token tersebut belum kedaluwarsa. 101 00:06:16,370 --> 00:06:18,190 ‫Sangat bagus. 102 00:06:18,190 --> 00:06:21,190 ‫Jadi, selanjutnya kami ingin, tentu saja, mengirim 103 00:06:21,190 --> 00:06:25,530 ‫kesalahan jika tidak ada pengguna, atau pada dasarnya, jika token telah kedaluwarsa. 104 00:06:25,530 --> 00:06:27,230 ‫Tapi itu, dalam hal 105 00:06:27,230 --> 00:06:30,500 ‫ini, sama, karena jika token telah kedaluwarsa, maka itu 106 00:06:30,500 --> 00:06:32,513 ‫tidak akan mengembalikan pengguna mana pun. 107 00:06:33,956 --> 00:06:37,730 ‫Jadi yang perlu kita lakukan adalah mengatakan, jika 108 00:06:38,970 --> 00:06:43,970 ‫tidak ada pengguna, maka, seperti biasa, kembali berikutnya, itu bukan mext. 109 00:06:47,920 --> 00:06:51,910 ‫Jadi AppError baru, dan 110 00:06:51,910 --> 00:06:56,793 ‫katakanlah Token tidak valid atau telah kedaluwarsa. 111 00:06:59,850 --> 00:07:02,853 ‫Dan kemudian 400, permintaan yang sangat buruk. 112 00:07:04,140 --> 00:07:07,050 ‫Jadi, jika tidak ada kesalahan, dan 113 00:07:07,050 --> 00:07:09,400 ‫jika berikutnya tidak dipanggil, 114 00:07:09,400 --> 00:07:12,160 ‫maka mari kita atur kata sandinya. 115 00:07:12,160 --> 00:07:15,550 ‫Jadi, kami sudah mendapatkan pengguna dan sekarang sangat 116 00:07:15,550 --> 00:07:20,550 ‫sederhana: pengguna. kata sandi sama dengan req. tubuh. kata sandi. 117 00:07:24,880 --> 00:07:28,140 ‫Dan itu karena kami tentu saja akan 118 00:07:28,140 --> 00:07:31,713 ‫mengirimkan kata sandi dan juga kata sandiKonfirmasi melalui badan. 119 00:07:33,551 --> 00:07:34,701 ‫Jadi mari kita gandakan 120 00:07:37,870 --> 00:07:39,553 ‫itu dan konfirmasi kata sandi juga. 121 00:07:41,425 --> 00:07:44,630 ‫Dan juga, mari kita pada dasarnya menghapus token reset 122 00:07:44,630 --> 00:07:45,733 ‫dan yang kedaluwarsa. 123 00:07:46,800 --> 00:07:51,800 ‫Jadi passwordResetToken, jadi seperti yang kita lakukan sebelumnya, kita set ke 124 00:07:52,040 --> 00:07:57,037 ‫undefined, dan sekarang user. kata sandi kedaluwarsa sama dengan 125 00:07:59,510 --> 00:08:01,160 ‫tidak terdefinisi. 126 00:08:01,160 --> 00:08:02,220 ‫Baiklah. 127 00:08:02,220 --> 00:08:04,350 ‫Dan lagi, tentu saja, sekarang kita 128 00:08:04,350 --> 00:08:07,000 ‫perlu menyimpannya, karena ini hanya mengubah dokumen, 129 00:08:07,000 --> 00:08:08,410 ‫tidak benar-benar memperbarui. 130 00:08:08,410 --> 00:08:09,973 ‫Jadi itu tidak benar-benar menyelamatkannya. 131 00:08:11,200 --> 00:08:15,503 ‫Jadi, tunggu pengguna. menyimpan. 132 00:08:17,500 --> 00:08:20,350 ‫Dan dalam hal ini sebenarnya kita 133 00:08:20,350 --> 00:08:24,340 ‫tidak perlu mematikan validator, karena memang kita ingin melakukan validasi. 134 00:08:24,340 --> 00:08:27,620 ‫Misalnya, kami ingin validator mengonfirmasi 135 00:08:27,620 --> 00:08:31,440 ‫apakah kata sandi sama dengan kata sandiKonfirmasi. 136 00:08:31,440 --> 00:08:33,380 ‫Dan validator itu secara otomatis melakukan 137 00:08:33,380 --> 00:08:35,033 ‫semua itu untuk kita. 138 00:08:36,800 --> 00:08:39,390 ‫Kemudian langkah ketiga, apa yang akan kita 139 00:08:39,390 --> 00:08:42,030 ‫lakukan pada akhirnya, dan apa yang akan kita 140 00:08:42,030 --> 00:08:43,990 ‫lakukan selanjutnya adalah mengunci pengguna. 141 00:08:43,990 --> 00:08:47,400 ‫Jadi dengan kata lain, kirim JSON Web Token. 142 00:08:47,400 --> 00:08:51,930 ‫Dan mari kita ambil kode itu dari sini, jadi yang ini. 143 00:08:51,930 --> 00:08:53,770 ‫Dan sekali lagi, kami sudah 144 00:08:53,770 --> 00:08:55,700 ‫melakukan ini di tiga tempat berbeda. 145 00:08:55,700 --> 00:08:59,280 ‫Jadi di sini di login, juga di signup, dan sekarang 146 00:08:59,280 --> 00:09:01,400 ‫untuk ketiga kalinya, di sini. 147 00:09:01,400 --> 00:09:05,170 ‫Jadi, suatu saat nanti, kami akan refactor itu menjadi 148 00:09:05,170 --> 00:09:06,383 ‫fungsinya sendiri. 149 00:09:07,230 --> 00:09:09,673 ‫Tapi untuk saat ini, kami baik-baik saja seperti ini. 150 00:09:11,180 --> 00:09:14,743 ‫Jadi, sekarang mari kita lanjutkan dan uji ini. 151 00:09:16,710 --> 00:09:19,020 ‫Jadi token reset yang 152 00:09:19,020 --> 00:09:22,080 ‫kita miliki sebelumnya sudah kedaluwarsa, jadi pada 153 00:09:22,080 --> 00:09:24,640 ‫dasarnya kita perlu meminta yang baru. 154 00:09:24,640 --> 00:09:29,490 ‫Jadi mari datang ke Postman dan tekan rute lupa kata sandi kami. 155 00:09:29,490 --> 00:09:32,120 ‫Mari kita kurangi kekacauan di 156 00:09:32,120 --> 00:09:36,350 ‫sini dan singkirkan semua tab terbuka yang tidak lagi 157 00:09:36,350 --> 00:09:37,500 ‫kita perlukan. 158 00:09:38,910 --> 00:09:41,150 ‫Sebenarnya di sini kita akan membutuhkan 159 00:09:43,480 --> 00:09:45,270 ‫tes ini untuk Reset Password 160 00:09:45,270 --> 00:09:48,210 ‫ini, karena ingat, yang ini benar-benar mendapatkan kembali Token 161 00:09:48,210 --> 00:09:51,540 ‫Web JSON, dan jadi kami ingin menyimpannya ke dalam variabel 162 00:09:51,540 --> 00:09:52,890 ‫lingkungan, seperti yang 163 00:09:52,890 --> 00:09:54,830 ‫kami lakukan dengan yang lainnya. 164 00:09:54,830 --> 00:09:58,373 ‫Jadi saya melakukan itu sekarang, hanya agar saya tidak melupakannya. 165 00:10:00,550 --> 00:10:04,100 ‫Baiklah, bagaimanapun, mari kita mulai dengan, pada dasarnya, 166 00:10:04,100 --> 00:10:05,690 ‫melupakan kata sandi. 167 00:10:05,690 --> 00:10:08,620 ‫Jadi mengirimkan permintaan itu, yang sekali lagi, membutuhkan 168 00:10:08,620 --> 00:10:10,750 ‫waktu karena mengirim email, tapi 169 00:10:10,750 --> 00:10:14,947 ‫ini dia, dan sekarang mari kita pergi ke email kita, dan itu 170 00:10:16,880 --> 00:10:19,463 ‫baru saja tiba beberapa detik yang lalu. 171 00:10:20,670 --> 00:10:24,890 ‫Jadi, ini, tentu saja, token ini. 172 00:10:24,890 --> 00:10:29,890 ‫Jadi mari kita ambil, salin dan sekarang kembali ke Postman, kita 173 00:10:31,060 --> 00:10:34,303 ‫menggunakannya di Reset Password, sebagai URL. 174 00:10:35,750 --> 00:10:37,253 ‫Oke, masuk akal? 175 00:10:38,250 --> 00:10:41,603 ‫Jadi sekali lagi, kami mengirimkan token itu tepat di URL. 176 00:10:43,600 --> 00:10:45,730 ‫Kemudian di sini, mari tentukan 177 00:10:45,730 --> 00:10:49,453 ‫isi, karena sekarang, kita perlu benar-benar menentukan kata sandi baru kita. 178 00:10:53,720 --> 00:10:57,843 ‫Jadi kata sandi dan katakanlah newpass. 179 00:11:01,650 --> 00:11:03,050 ‫Lalu... 180 00:11:05,950 --> 00:11:07,450 ‫Dan di sini sebut saja 181 00:11:07,450 --> 00:11:10,263 ‫sesuatu yang lain, karena untuk saat ini, saya sebenarnya ingin melihat kesalahan. 182 00:11:11,480 --> 00:11:14,727 ‫Dan tentu saja, ini disebut passwordConfirm. 183 00:11:17,360 --> 00:11:20,393 ‫Jadi mari kita lihat apa yang terjadi ketika kita mencoba melakukan ini. 184 00:11:23,240 --> 00:11:27,080 ‫Mari kita tunggu, dan kita mendapatkan kata sandi lebih 185 00:11:27,080 --> 00:11:29,640 ‫pendek dari panjang minimum yang diizinkan. 186 00:11:29,640 --> 00:11:34,480 ‫Oke, jadi mari kita ubah itu, 123, dan di sini katakanlah 1234. 187 00:11:36,090 --> 00:11:37,740 ‫Jadi saya ingin mereka berbeda. 188 00:11:37,740 --> 00:11:40,630 ‫Tetapi Anda melihat bahwa validasi di sini berfungsi dengan 189 00:11:40,630 --> 00:11:43,273 ‫baik, bahkan ketika memperbarui kata sandi dengan simpan. 190 00:11:45,610 --> 00:11:48,800 ‫Jadi, dan sekarang kita mendapatkan Password yang tidak sama! 191 00:11:48,800 --> 00:11:50,960 ‫Jadi sekali lagi, itu adalah kesalahan validasi. 192 00:11:50,960 --> 00:11:53,430 ‫Dan ingat, sebenarnya, inilah alasan mengapa 193 00:11:53,430 --> 00:11:56,213 ‫kita perlu menggunakan save and not update. 194 00:11:57,206 --> 00:11:59,090 ‫Jadi sebelumnya, untuk memperbarui 195 00:11:59,090 --> 00:12:03,220 ‫tur, kami biasanya menggunakan findOneAndUpdate, tetapi sekarang, untuk semua 196 00:12:03,220 --> 00:12:06,820 ‫yang terkait dengan kata sandi dan pengguna, kami 197 00:12:06,820 --> 00:12:10,110 ‫selalu menggunakan save, karena kami selalu ingin 198 00:12:10,110 --> 00:12:12,580 ‫menjalankan semua validator, dan yang terpenting, 199 00:12:12,580 --> 00:12:14,450 ‫fungsi save middleware. 200 00:12:14,450 --> 00:12:18,293 ‫Jadi, misalnya, yang kata sandinya dienkripsi. 201 00:12:20,400 --> 00:12:21,610 ‫Jadi mari kita akhiri sekarang. 202 00:12:21,610 --> 00:12:25,030 ‫Oh, saya tidak benar-benar memperbaikinya, maaf untuk itu. 203 00:12:25,030 --> 00:12:28,230 ‫Dan sekarang itu harus benar-benar berfungsi. 204 00:12:28,230 --> 00:12:32,870 ‫Dan memang, kami mendapatkan kesuksesan, dan kami mendapatkan token baru. 205 00:12:32,870 --> 00:12:36,600 ‫Hebat, mari kita lihat apakah token ini benar-benar valid. 206 00:12:36,600 --> 00:12:40,973 ‫Jadi jika kami bisa, dapatkan semua tur menggunakan token baru ini. 207 00:12:43,870 --> 00:12:46,210 ‫Dan ini dia. 208 00:12:46,210 --> 00:12:51,000 ‫Jadi, token baru kami benar-benar berfungsi, dan sekarang untuk pengguna 209 00:12:51,000 --> 00:12:53,990 ‫ini, jadi untuk hello@jonas, kedua properti 210 00:12:53,990 --> 00:12:56,190 ‫ini harus benar-benar hilang. 211 00:12:56,190 --> 00:12:59,760 ‫Jadi kata sandinya kedaluwarsa dan tokennya harus hilang, 212 00:12:59,760 --> 00:13:03,550 ‫karena, yah, karena itulah yang kami lakukan dalam kode kami. 213 00:13:03,550 --> 00:13:06,760 ‫Jadi, ya, mereka tidak lagi di sini. 214 00:13:06,760 --> 00:13:10,210 ‫Sekarang yang perlu kita lakukan sebenarnya, adalah langkah yang hilang ini 215 00:13:10,210 --> 00:13:12,690 ‫di sini, yaitu memperbarui properti passwordAt untuk 216 00:13:13,610 --> 00:13:14,773 ‫pengguna saat ini. 217 00:13:15,680 --> 00:13:17,260 ‫Tapi itu seharusnya 218 00:13:17,260 --> 00:13:20,690 ‫tidak terlalu sulit, jadi mari kita cepat kembali 219 00:13:20,690 --> 00:13:24,550 ‫ke userModel, di mana kita akan melakukannya menggunakan middleware. 220 00:13:24,550 --> 00:13:26,800 ‫Dan mari kita menempatkan semua middleware 221 00:13:26,800 --> 00:13:29,023 ‫bersama-sama di sini di atas. 222 00:13:32,241 --> 00:13:35,408 ‫Jadi, skema pengguna. pra dan 223 00:13:38,830 --> 00:13:42,763 ‫lagi titik simpan, dan kemudian fungsi dengan berikutnya. 224 00:13:44,850 --> 00:13:47,010 ‫Sekali lagi, fungsi ini di 225 00:13:47,010 --> 00:13:50,890 ‫sini akan berjalan tepat sebelum dokumen baru benar-benar disimpan. 226 00:13:50,890 --> 00:13:52,220 ‫Jadi, ini adalah 227 00:13:52,220 --> 00:13:54,880 ‫tempat yang tepat untuk benar-benar menentukan properti ini. 228 00:13:54,880 --> 00:13:57,480 ‫Dan saya, tentu saja, dapat melakukannya di pengontrol 229 00:13:58,820 --> 00:14:01,133 ‫tepat di sebelah kode ini, misalnya. 230 00:14:02,310 --> 00:14:05,853 ‫Tapi saya benar-benar ingin ini terjadi, secara otomatis. 231 00:14:06,740 --> 00:14:08,700 ‫Jadi, semacam di belakang layar. 232 00:14:08,700 --> 00:14:11,350 ‫Karena nanti, kami akan memiliki tempat lain di 233 00:14:11,350 --> 00:14:15,290 ‫mana kami memperbarui kata sandi dan kemudian kami akan memastikan bahwa kami 234 00:14:15,290 --> 00:14:17,410 ‫memasukkan kode yang sama di sana. 235 00:14:17,410 --> 00:14:19,300 ‫Dan seperti ini, sekali lagi, 236 00:14:19,300 --> 00:14:20,640 ‫itu terjadi, semacam, 237 00:14:20,640 --> 00:14:23,810 ‫di belakang layar, tanpa kita harus mengkhawatirkannya sama sekali. 238 00:14:23,810 --> 00:14:26,600 ‫Sekarang, kapan tepatnya kita 239 00:14:26,600 --> 00:14:30,630 ‫ingin menyetel properti passwordChangedAt menjadi sekarang? 240 00:14:30,630 --> 00:14:33,450 ‫Kami hanya menginginkannya ketika kami benar-benar mengubah 241 00:14:33,450 --> 00:14:34,660 ‫properti kata sandi. 242 00:14:34,660 --> 00:14:37,290 ‫Dan saya tidak yakin apakah kita pernah menggunakan trik 243 00:14:37,290 --> 00:14:39,660 ‫ini sebelumnya, tapi bagaimanapun, mari kita gunakan sekarang. 244 00:14:39,660 --> 00:14:44,660 ‫Jadi kalau belum kita modifikasi, ya kalau tidak ini. isModified, jadi seperti ini, 245 00:14:47,620 --> 00:14:49,100 ‫dan 246 00:14:49,100 --> 00:14:53,070 ‫kemudian nama properti, jadi kata sandi. 247 00:14:53,070 --> 00:14:56,380 ‫Jadi dalam hal ini, segera kembali dan 248 00:14:57,270 --> 00:14:59,360 ‫jalankan middleware berikutnya. 249 00:14:59,360 --> 00:15:02,823 ‫Oke, tidak seperti ini, tapi seperti ini. 250 00:15:04,380 --> 00:15:07,770 ‫Jadi sekali lagi, jika kita tidak 251 00:15:07,770 --> 00:15:08,770 ‫mengubah 252 00:15:08,770 --> 00:15:12,970 ‫properti password, tentu saja, jangan memanipulasi passwordChangedAt. 253 00:15:12,970 --> 00:15:15,860 ‫Tapi bagaimana dengan membuat dokumen baru? 254 00:15:15,860 --> 00:15:18,010 ‫Nah, ketika kita membuat dokumen baru, 255 00:15:18,010 --> 00:15:20,150 ‫maka kita benar-benar memodifikasi 256 00:15:20,150 --> 00:15:24,350 ‫kata sandi, dan kemudian kita akan mengatur properti kata sandiChangedAt, kan? 257 00:15:24,350 --> 00:15:27,260 ‫Nah, dalam implementasi saat ini sebenarnya kita akan melakukannya. 258 00:15:27,260 --> 00:15:29,860 ‫Tapi ada hal lain yang bisa kita gunakan di sini. 259 00:15:29,860 --> 00:15:32,950 ‫Jadi, pada dasarnya, kami ingin segera keluar 260 00:15:32,950 --> 00:15:36,630 ‫dari fungsi middleware ini, jika kata sandinya belum diubah 261 00:15:36,630 --> 00:15:40,274 ‫atau jika dokumennya baru, sehingga kami dapat menggunakan 262 00:15:40,274 --> 00:15:41,633 ‫properti isNew. 263 00:15:42,700 --> 00:15:46,210 ‫Dan sekali lagi, ini adalah salah satu hal yang sangat bagus 264 00:15:46,210 --> 00:15:48,290 ‫yang dipelajari dengan membaca dokumentasi Anda. 265 00:15:48,290 --> 00:15:52,010 ‫Jadi, saya tidak bisa cukup menekankan betapa pentingnya untuk benar-benar membaca 266 00:15:52,010 --> 00:15:55,160 ‫dokumentasi ketika Anda membutuhkan sesuatu yang tidak dapat Anda 267 00:15:55,160 --> 00:15:56,870 ‫temukan di mana pun. 268 00:15:56,870 --> 00:15:59,010 ‫Karena, sebenarnya ada begitu banyak hal 269 00:15:59,010 --> 00:16:02,983 ‫di sana yang sama sekali tidak mungkin untuk diajarkan dalam satu mata kuliah. 270 00:16:04,810 --> 00:16:08,500 ‫Bagaimanapun, jika kode melewati verifikasi ini di 271 00:16:08,500 --> 00:16:10,830 ‫sini, maka katakan saja, 272 00:16:10,830 --> 00:16:14,217 ‫ini. passwordChangedAt = Tanggal. sekarang. 273 00:16:18,660 --> 00:16:22,303 ‫Dan kemudian, kami menelepon berikutnya. 274 00:16:23,640 --> 00:16:26,300 ‫Sekarang, secara teori, ini seharusnya berfungsi dengan 275 00:16:26,300 --> 00:16:27,590 ‫baik, tetapi sebenarnya, 276 00:16:27,590 --> 00:16:30,160 ‫dalam praktiknya, terkadang masalah kecil terjadi. 277 00:16:30,160 --> 00:16:33,580 ‫Dan masalahnya terkadang menyimpan ke database sedikit 278 00:16:33,580 --> 00:16:37,440 ‫lebih lambat daripada mengeluarkan JSON Web Token, sehingga 279 00:16:37,440 --> 00:16:40,460 ‫timestamp kata sandi yang diubah terkadang 280 00:16:40,460 --> 00:16:42,560 ‫diatur sedikit setelah 281 00:16:42,560 --> 00:16:45,280 ‫JSON Web Token dibuat. 282 00:16:45,280 --> 00:16:48,000 ‫Dan itu kemudian akan membuat pengguna 283 00:16:48,000 --> 00:16:51,120 ‫tidak akan bisa login menggunakan token baru. 284 00:16:51,120 --> 00:16:54,570 ‫Karena, ingat, alasan mengapa stempel waktu ini benar-benar 285 00:16:54,570 --> 00:16:57,660 ‫ada, adalah agar kita dapat membandingkannya 286 00:16:57,660 --> 00:17:01,200 ‫dengan stempel waktu di JSON Web Token, bukan? 287 00:17:01,200 --> 00:17:04,353 ‫Jadi, untuk diingat, ya, jadi 288 00:17:05,930 --> 00:17:10,930 ‫di sini, di mana kami memeriksa apakah pengguna telah 289 00:17:11,560 --> 00:17:15,170 ‫mengubah kata sandi setelah token dikeluarkan. 290 00:17:15,170 --> 00:17:18,920 ‫Jadi, di sini, di mana kami kemudian membuat token 291 00:17:18,920 --> 00:17:21,010 ‫baru ini di reset password. 292 00:17:21,010 --> 00:17:24,170 ‫Jadi di sini, ingat, kita membuat 293 00:17:24,170 --> 00:17:27,770 ‫token baru ini, dan sekali lagi, terkadang token 294 00:17:27,770 --> 00:17:31,500 ‫ini dibuat sedikit sebelum cap waktu kata sandi 295 00:17:31,500 --> 00:17:33,960 ‫yang diubah benar-benar dibuat. 296 00:17:33,960 --> 00:17:38,960 ‫Jadi, kita hanya perlu memperbaikinya dengan mengurangi satu detik. 297 00:17:39,610 --> 00:17:42,733 ‫Jadi, pada dasarnya, seribu milidetik. 298 00:17:43,750 --> 00:17:47,670 ‫Dan kemudian akan menempatkan passwordChangedAt satu detik di masa lalu, 299 00:17:47,670 --> 00:17:50,840 ‫oke, yang tentu saja, tidak 100% 300 00:17:50,840 --> 00:17:54,500 ‫akurat, tapi itu tidak masalah sama sekali, karena satu 301 00:17:54,500 --> 00:17:58,000 ‫detik di sini tidak ada bedanya sama sekali. 302 00:17:58,000 --> 00:18:01,213 ‫Ini adalah peretasan kecil, tetapi sekali lagi, itu tidak masalah. 303 00:18:02,190 --> 00:18:06,190 ‫Jadi menempatkan passwordChanged ini satu detik di masa lalu, 304 00:18:06,190 --> 00:18:08,920 ‫maka akan memastikan bahwa token selalu 305 00:18:08,920 --> 00:18:11,433 ‫dibuat setelah password diubah. 306 00:18:13,290 --> 00:18:15,800 ‫Jadi, ini berfungsi sekarang, tetapi seperti 307 00:18:15,800 --> 00:18:18,380 ‫biasa, mari kita juga mengujinya dengan cepat. 308 00:18:18,380 --> 00:18:21,060 ‫Oke, jadi kembali ke tukang pos. 309 00:18:21,060 --> 00:18:23,990 ‫Mari kita lakukan Reset Kata Sandi baru, atau sebenarnya, 310 00:18:23,990 --> 00:18:26,060 ‫bukan itu yang saya inginkan sama 311 00:18:26,060 --> 00:18:28,400 ‫sekali, tetapi merupakan hal yang hebat untuk melihat 312 00:18:28,400 --> 00:18:30,200 ‫bahwa kode tersebut benar-benar berfungsi. 313 00:18:30,200 --> 00:18:33,610 ‫Jadi, Token tidak valid atau telah kedaluwarsa, dan itu 314 00:18:33,610 --> 00:18:35,999 ‫karena, yah, 10 menit telah 315 00:18:35,999 --> 00:18:38,640 ‫berlalu sejak saya benar-benar membuat token itu. 316 00:18:38,640 --> 00:18:41,240 ‫Dan saya pikir kami belum menguji 317 00:18:41,240 --> 00:18:45,043 ‫ini, dan sangat bagus bahwa sekarang secara tidak sengaja, benar-benar melakukannya. 318 00:18:46,370 --> 00:18:50,160 ‫Jadi sekali lagi, ini datang, jika Anda bertanya-tanya apa yang 319 00:18:50,160 --> 00:18:51,493 ‫terjadi, jadi tentu 320 00:18:53,840 --> 00:18:56,500 ‫saja pesan kesalahan ini di sini. 321 00:18:56,500 --> 00:18:59,450 ‫Dan itu berarti, tidak menemukan pengguna yang 322 00:18:59,450 --> 00:19:03,216 ‫memiliki token ini atau yang memiliki token lebih dari 323 00:19:03,216 --> 00:19:05,163 ‫10 menit yang lalu. 324 00:19:06,600 --> 00:19:10,393 ‫Jadi, memang yang ingin saya lakukan, adalah melupakan kata sandi. 325 00:19:12,700 --> 00:19:14,073 ‫Jadi, mari kita tunggu saja. 326 00:19:18,000 --> 00:19:19,980 ‫Jadi 8. 6 detik, 327 00:19:19,980 --> 00:19:22,820 ‫tapi itu mungkin karena koneksi internet saya. 328 00:19:22,820 --> 00:19:24,520 ‫Jadi jika Anda menjalankan ini 329 00:19:24,520 --> 00:19:26,373 ‫di server, mungkin akan jauh lebih cepat. 330 00:19:27,440 --> 00:19:31,900 ‫Jadi mari kita ambil itu di sini, kembali ke tukang pos, dan 331 00:19:31,900 --> 00:19:36,740 ‫sekarang kita mengatur ulang kata sandi, sekali lagi dengan kata sandi ini, tidak 332 00:19:36,740 --> 00:19:39,823 ‫masalah apakah itu sama dengan yang lama. 333 00:19:40,690 --> 00:19:43,580 ‫Dan, jadi sekarang kami memiliki kesuksesan kami di sini. 334 00:19:43,580 --> 00:19:45,193 ‫Dan sekarang kembali ke Kompas. 335 00:19:46,680 --> 00:19:51,210 ‫Mari kita reload, dan memang, kita mendapatkan passwordChangedAt. 336 00:19:51,210 --> 00:19:53,290 ‫Dan itu benar-benar terjadi sekarang. 337 00:19:53,290 --> 00:19:57,220 ‫Jadi, jika sekarang kita mencoba untuk benar-benar menggunakan token ini, misalnya, 338 00:19:57,220 --> 00:19:59,870 ‫untuk mengakses rute yang dilindungi ini, maka 339 00:19:59,870 --> 00:20:02,130 ‫itu akan berhasil karena tag 340 00:20:02,130 --> 00:20:04,633 ‫kecil, satu detik yang kita lakukan. 341 00:20:06,090 --> 00:20:10,205 ‫Jadi, begitulah dan seperti ini, kami sebenarnya sekarang menyelesaikan 342 00:20:10,205 --> 00:20:12,840 ‫Fungsi Reset Kata Sandi kami. 343 00:20:12,840 --> 00:20:16,400 ‫Jadi itu sedikit kode, tapi tentu saja, 344 00:20:16,400 --> 00:20:18,100 ‫itu sangat berharga. 345 00:20:18,100 --> 00:20:20,470 ‫Jadi, Anda harus selalu menawarkan 346 00:20:20,470 --> 00:20:22,874 ‫fungsionalitas ini di aplikasi web Anda, 347 00:20:22,874 --> 00:20:26,750 ‫karena jika tidak, pengguna yang lupa kata sandinya benar-benar kacau, 348 00:20:26,750 --> 00:20:29,140 ‫mereka tidak dapat lagi menggunakan aplikasi 349 00:20:29,140 --> 00:20:31,940 ‫Anda, jadi, itu tentu saja praktik yang buruk. 350 00:20:31,940 --> 00:20:34,020 ‫Bagaimanapun, jenis ini 351 00:20:34,020 --> 00:20:38,520 ‫sudah selesai, bagian otentikasi dan otorisasi dari bagian ini. 352 00:20:38,520 --> 00:20:40,510 ‫Jadi sekali lagi, ini 353 00:20:40,510 --> 00:20:43,250 ‫cukup lengkap dan saya sangat senang mengimplementasikannya. 354 00:20:43,250 --> 00:20:46,341 ‫Jadi, bagian ini bagi saya adalah tempat 355 00:20:46,341 --> 00:20:48,560 ‫aplikasi web benar-benar mulai hidup. 356 00:20:48,560 --> 00:20:51,280 ‫Saya tahu bahwa itu tidak benar-benar terlihat pada saat 357 00:20:51,280 --> 00:20:54,280 ‫ini, dengan semua ini, hanya token dan menyalin token 358 00:20:54,280 --> 00:20:56,300 ‫dan menempelkannya di tempat lain. 359 00:20:56,300 --> 00:20:59,630 ‫Itu bukan ide yang biasa kita miliki untuk masuk, saya 360 00:20:59,630 --> 00:21:02,410 ‫tahu, tapi tentu saja, sedikit kemudian, ketika kita 361 00:21:02,410 --> 00:21:05,430 ‫akhirnya mulai membangun situs web dinamis, maka tentu 362 00:21:05,430 --> 00:21:06,580 ‫saja kita 363 00:21:06,580 --> 00:21:09,220 ‫akan tetap menggunakan otentikasi yang baru saja 364 00:21:09,220 --> 00:21:13,350 ‫kita buat dan kemudian juga akan menjadi visual pada website dinamis tersebut. 365 00:21:13,350 --> 00:21:16,833 ‫Selanjutnya, kami akan mengimplementasikan fungsionalitas untuk memperbarui pengguna 366 00:21:16,833 --> 00:21:19,620 ‫dan juga menghapusnya, dan setelah 367 00:21:19,620 --> 00:21:22,990 ‫itu, kami juga akan berbicara tentang keamanan. 368 00:21:22,990 --> 00:21:25,800 ‫Jadi itulah yang ada di depan untuk sisa 369 00:21:25,800 --> 00:21:28,323 ‫bagian ini, jadi pastikan untuk tidak melewatkannya.