1 00:00:01,040 --> 00:00:03,970 ‫Narator: Sejauh ini dalam implementasi otentikasi 2 00:00:03,970 --> 00:00:07,780 ‫kami, kami telah memasukkan pengguna dengan kata sandi yang benar. 3 00:00:07,780 --> 00:00:11,170 ‫Jadi pada dasarnya kami menyelesaikan langkah pertama dari 4 00:00:11,170 --> 00:00:13,170 ‫alur kerja otentikasi ini 5 00:00:13,170 --> 00:00:15,760 ‫di mana token web JSON dibuat 6 00:00:15,760 --> 00:00:18,730 ‫dan dikirim kembali ke klien jika pengguna 7 00:00:18,730 --> 00:00:21,440 ‫memberikan email dan kata sandi yang benar. 8 00:00:21,440 --> 00:00:25,350 ‫Jadi selanjutnya kita akan benar-benar menerapkan rute yang dilindungi. 9 00:00:25,350 --> 00:00:28,630 ‫Jadi pada dasarnya menggunakan token web JSON yang 10 00:00:28,630 --> 00:00:32,930 ‫dibuat untuk memberi pengguna yang masuk akses ke rute yang dilindungi. 11 00:00:32,930 --> 00:00:36,220 ‫Dan ini adalah langkah kedua otentikasi. 12 00:00:36,220 --> 00:00:39,823 ‫Jadi sekarang mari kita lanjutkan dan implementasikan fungsi ini. 13 00:00:41,620 --> 00:00:43,880 ‫Jadi katakanlah kita ingin 14 00:00:43,880 --> 00:00:45,670 ‫melindungi rute getAllTours. 15 00:00:45,670 --> 00:00:48,470 ‫Jadi pada dasarnya hanya mengizinkan pengguna yang 16 00:00:48,470 --> 00:00:51,560 ‫masuk untuk mendapatkan akses ke daftar semua tur kami. 17 00:00:51,560 --> 00:00:53,830 ‫Dan apa artinya sebelum menjalankan handler 18 00:00:53,830 --> 00:00:55,700 ‫get all tours, jadi mari 19 00:00:55,700 --> 00:00:57,353 ‫kita lihat itu. 20 00:00:58,340 --> 00:01:01,330 ‫Oke, jadi sebelum menjalankan pegangan ini di 21 00:01:01,330 --> 00:01:03,240 ‫sini, kita perlu melakukan beberapa 22 00:01:03,240 --> 00:01:05,120 ‫pemeriksaan untuk memverifikasi 23 00:01:05,120 --> 00:01:07,760 ‫apakah pengguna benar-benar masuk atau tidak, bukan? 24 00:01:07,760 --> 00:01:09,540 ‫Jadi cara terbaik untuk 25 00:01:09,540 --> 00:01:11,640 ‫melakukannya seperti yang mungkin sudah 26 00:01:11,640 --> 00:01:15,160 ‫Anda ketahui saat ini, adalah dengan menggunakan fungsi middleware, oke? 27 00:01:15,160 --> 00:01:17,300 ‫Jadi dalam video ini, 28 00:01:17,300 --> 00:01:19,640 ‫untuk melindungi rute, kita akan membuat 29 00:01:19,640 --> 00:01:23,560 ‫fungsi middleware yang akan dijalankan sebelum masing-masing handler ini, oke. 30 00:01:23,560 --> 00:01:26,320 ‫Jadi fungsi yang akan duduk di sini, 31 00:01:26,320 --> 00:01:29,440 ‫jadi sebelum fungsi ini di sini bisa berjalan. 32 00:01:29,440 --> 00:01:32,050 ‫Dan middleware ini kemudian akan mengembalikan 33 00:01:32,050 --> 00:01:34,140 ‫kesalahan jika pengguna tidak diautentikasi, 34 00:01:34,140 --> 00:01:35,850 ‫jadi jika dia 35 00:01:35,850 --> 00:01:37,780 ‫tidak login, atau akan memanggil 36 00:01:37,780 --> 00:01:42,150 ‫middleware berikutnya yang dalam hal ini adalah handler getAllTours, bukan? 37 00:01:42,150 --> 00:01:44,730 ‫Dan itu efektif melindungi rute ini 38 00:01:44,730 --> 00:01:47,080 ‫dari akses yang tidak sah. 39 00:01:47,080 --> 00:01:48,810 ‫Jadi mari kita lanjutkan dan dengan 40 00:01:48,810 --> 00:01:50,290 ‫cepat membuat fungsi middleware itu 41 00:01:50,290 --> 00:01:51,480 ‫dan meletakkannya di 42 00:01:51,480 --> 00:01:54,060 ‫sini untuk mengilustrasikan apa yang baru saja saya katakan. 43 00:01:54,060 --> 00:01:57,620 ‫Oke, jadi di sini di pengontrol auth kami 44 00:01:57,620 --> 00:02:00,170 ‫lagi kami akan membuat fungsi middleware 45 00:02:03,920 --> 00:02:06,283 ‫baru dan itu disebut melindungi. 46 00:02:08,510 --> 00:02:09,343 ‫Baiklah, 47 00:02:09,343 --> 00:02:11,600 ‫dan seperti sebelumnya saya akan menggunakan 48 00:02:12,480 --> 00:02:14,740 ‫catchAsync karena sekali lagi semua fungsi 49 00:02:14,740 --> 00:02:16,553 ‫ini sebenarnya adalah fungsi async. 50 00:02:17,990 --> 00:02:21,210 ‫Baiklah, dan kemudian di sini tentu saja, fungsi middleware 51 00:02:24,320 --> 00:02:27,270 ‫kita dan untuk saat ini mari kita panggil 52 00:02:27,270 --> 00:02:30,190 ‫next here saja agar kita benar-benar memiliki tubuh 53 00:02:30,190 --> 00:02:32,240 ‫apa pun di sini dalam 54 00:02:32,240 --> 00:02:35,090 ‫fungsi middleware ini dan kemudian mari kembali ke 55 00:02:35,090 --> 00:02:38,540 ‫rute tur kita dan kemudian lindungi rute ini, oke ? 56 00:02:38,540 --> 00:02:42,190 ‫Jadi pertama-tama saya harus benar-benar membutuhkan modul 57 00:02:42,190 --> 00:02:44,620 ‫pengontrol otentikasi ini. 58 00:02:44,620 --> 00:02:45,453 ‫Jadi 59 00:02:50,550 --> 00:02:52,350 ‫const dan kemudian memerlukannya 60 00:02:56,410 --> 00:02:57,920 ‫di pengontrol, 61 00:02:57,920 --> 00:02:59,713 ‫dan kemudian authController, oke. 62 00:03:01,430 --> 00:03:04,150 ‫Jadi sekarang mari kita 63 00:03:04,150 --> 00:03:07,460 ‫pasang, di sini di rute getAllTours. 64 00:03:07,460 --> 00:03:08,293 ‫Oke. 65 00:03:09,550 --> 00:03:13,913 ‫Jadi authController. melindungi. 66 00:03:14,860 --> 00:03:15,693 ‫Oke. 67 00:03:15,693 --> 00:03:18,740 ‫Dan saat ini fungsi middleware ini akan dijalankan 68 00:03:18,740 --> 00:03:21,875 ‫terlebih dahulu, jika pengguna tidak diautentikasi maka akan 69 00:03:21,875 --> 00:03:22,950 ‫terjadi kesalahan. 70 00:03:22,950 --> 00:03:25,070 ‫Dan tentu saja middleware 71 00:03:25,070 --> 00:03:26,690 ‫berikutnya sehingga yang 72 00:03:26,690 --> 00:03:30,540 ‫benar-benar mendapatkan dan mengirim semua tur tidak akan dieksekusi. 73 00:03:30,540 --> 00:03:31,373 ‫Oke. 74 00:03:31,373 --> 00:03:34,700 ‫Dan sekali lagi, ini akan secara efektif melindungi akses 75 00:03:34,700 --> 00:03:38,223 ‫ke sumber daya ini di sini dari pengguna yang tidak masuk. 76 00:03:39,250 --> 00:03:42,700 ‫Baiklah, jadi mari kita kembali ke sini. 77 00:03:42,700 --> 00:03:44,340 ‫Bukan rute 78 00:03:44,340 --> 00:03:45,993 ‫pengguna, tetapi pengontrol auth. 79 00:03:46,850 --> 00:03:49,760 ‫Baiklah, dan sekarang tentang penerapan middleware 80 00:03:49,760 --> 00:03:51,180 ‫pelindung ini. 81 00:03:51,180 --> 00:03:53,660 ‫Apa sebenarnya yang harus kita lakukan? 82 00:03:53,660 --> 00:03:56,583 ‫Baiklah, mari kita mulai dengan menjelaskan beberapa langkah di sini. 83 00:03:57,460 --> 00:04:00,660 ‫Baiklah, dan sebenarnya pertama-tama kita perlu menandai fungsi 84 00:04:00,660 --> 00:04:03,720 ‫ini sebagai Async, jika tidak, kita tidak 85 00:04:03,720 --> 00:04:05,630 ‫akan membutuhkan catchAsync, bukan? 86 00:04:05,630 --> 00:04:09,260 ‫Dan Anda akan melihat mengapa kita perlu ini menjadi 87 00:04:09,260 --> 00:04:11,360 ‫fungsi Async dalam sedetik, oke? 88 00:04:11,360 --> 00:04:13,760 ‫Tapi sekarang mari kita paparkan langkah-langkah 89 00:04:13,760 --> 00:04:16,803 ‫yang perlu kita ambil untuk menerapkan middleware pelindung ini. 90 00:04:18,460 --> 00:04:19,840 ‫Jadi seperti sebelumnya, saya 91 00:04:19,840 --> 00:04:21,990 ‫akan menempatkan langkah-langkah ini di sini sebagai komentar. 92 00:04:23,340 --> 00:04:26,173 ‫Pertama kita harus benar-benar mendapatkan token. 93 00:04:28,720 --> 00:04:29,553 ‫Dan 94 00:04:30,660 --> 00:04:32,610 ‫periksa apakah pada dasarnya ada, 95 00:04:32,610 --> 00:04:34,303 ‫jadi periksa apakah ada. 96 00:04:35,400 --> 00:04:39,113 ‫Kemudian selanjutnya kita perlu memvalidasi token. 97 00:04:41,860 --> 00:04:44,383 ‫Jadi ini pada dasarnya adalah langkah super 98 00:04:44,383 --> 00:04:48,900 ‫penting yang telah kita bicarakan sebelumnya di mana algoritma JWT memverifikasi apakah 99 00:04:48,900 --> 00:04:50,680 ‫tanda tangan itu valid atau 100 00:04:50,680 --> 00:04:51,513 ‫tidak. 101 00:04:51,513 --> 00:04:54,950 ‫Jadi karena itu apakah token itu valid atau tidak, oke? 102 00:04:54,950 --> 00:04:57,450 ‫Jadi sebenarnya mari kita sebut ini di sini verifikasi. 103 00:04:58,930 --> 00:05:01,680 ‫Saya pikir itulah yang kami sebut di slide di mana 104 00:05:01,680 --> 00:05:03,630 ‫kami berbicara tentang ini sebelumnya, baiklah. 105 00:05:03,630 --> 00:05:06,040 ‫Dan jika Anda tidak begitu ingat bagaimana cara 106 00:05:06,040 --> 00:05:07,350 ‫kerjanya, Anda dapat 107 00:05:07,350 --> 00:05:10,003 ‫selalu kembali dan menonton kembali ceramah itu, oke? 108 00:05:11,470 --> 00:05:15,750 ‫Kemudian selanjutnya, jadi jika verifikasi benar-benar berhasil maka kita juga 109 00:05:15,750 --> 00:05:18,930 ‫perlu memeriksa apakah pengguna yang mencoba mengakses 110 00:05:18,930 --> 00:05:21,870 ‫rute itu masih ada, oke? 111 00:05:21,870 --> 00:05:25,940 ‫Jadi periksa apakah pengguna masih ada, dan saya akan 112 00:05:25,940 --> 00:05:28,090 ‫berbicara lebih banyak tentang 113 00:05:28,090 --> 00:05:32,610 ‫mengapa setiap langkah ini diperlukan setelah kita mulai menerapkannya, oke? 114 00:05:32,610 --> 00:05:35,410 ‫Jadi untuk sekarang ini mungkin tidak begitu masuk akal bagi Anda, 115 00:05:35,410 --> 00:05:38,950 ‫tetapi sekali lagi saya akan berbicara tentang setiap pemberhentian begitu kita sampai di sana. 116 00:05:38,950 --> 00:05:39,783 ‫Baiklah? 117 00:05:39,783 --> 00:05:41,440 ‫Dan akhirnya kita juga 118 00:05:42,980 --> 00:05:43,813 ‫perlu 119 00:05:45,490 --> 00:05:47,000 ‫memeriksa apakah pengguna 120 00:05:50,090 --> 00:05:51,720 ‫mengubah kata sandi 121 00:05:53,060 --> 00:05:54,993 ‫setelah JWT dikeluarkan, oke? 122 00:05:56,690 --> 00:05:58,280 ‫Nah, anggap saja token 123 00:05:58,280 --> 00:06:01,060 ‫di sini, kami menyebutnya token di tempat lain, oke? 124 00:06:01,060 --> 00:06:03,320 ‫Dan hanya jika tidak ada masalah 125 00:06:03,320 --> 00:06:05,310 ‫di salah satu langkah ini 126 00:06:05,310 --> 00:06:08,480 ‫di sini saja maka selanjutnya akan dipanggil yang kemudian 127 00:06:08,480 --> 00:06:11,210 ‫akan mendapatkan akses ke rute yang kita lindungi. 128 00:06:11,210 --> 00:06:16,210 ‫Jadi dalam contoh kita saat ini, sekali lagi, handler getAllTours ini. 129 00:06:16,420 --> 00:06:17,610 ‫Benar? 130 00:06:17,610 --> 00:06:19,260 ‫Oke, tapi mari kita 131 00:06:19,260 --> 00:06:22,540 ‫kembali dan mulai menerapkan langkah pertama kita di sini. 132 00:06:22,540 --> 00:06:24,380 ‫Jadi pada dasarnya mendapatkan token 133 00:06:24,380 --> 00:06:26,860 ‫dan kemudian memeriksa apakah itu benar-benar ada. 134 00:06:26,860 --> 00:06:31,340 ‫Jadi praktik umum adalah mengirim token menggunakan header http 135 00:06:31,340 --> 00:06:33,380 ‫dengan permintaan, oke? 136 00:06:33,380 --> 00:06:36,580 ‫Jadi mari kita lihat bagaimana kita bisa mengatur header di Postman 137 00:06:36,580 --> 00:06:38,427 ‫untuk mengirimnya bersama dengan permintaan 138 00:06:38,427 --> 00:06:40,420 ‫dan kemudian juga bagaimana kita bisa mendapatkan 139 00:06:40,420 --> 00:06:42,410 ‫akses ke header ini di Express. 140 00:06:42,410 --> 00:06:45,300 ‫Dan mari kita lakukan yang pertama. 141 00:06:45,300 --> 00:06:50,300 ‫Jadi di sini di apt. js Saya pikir kami memiliki middleware 142 00:06:51,240 --> 00:06:54,610 ‫yang bagus di sini, jadi di sini mari kita 143 00:06:56,290 --> 00:06:59,890 ‫masuk ke permintaan konsol. headers, Oke, jadi 144 00:06:59,890 --> 00:07:03,250 ‫kita sudah membicarakan tentang http header sebelumnya, 145 00:07:03,250 --> 00:07:07,140 ‫jadi beginilah cara kita bisa mengaksesnya di Express. 146 00:07:07,140 --> 00:07:10,350 ‫Oke, jadi pada dasarnya ke header permintaan, 147 00:07:10,350 --> 00:07:13,753 ‫jadi yang bisa dikirim klien bersama dengan permintaan mereka. 148 00:07:14,600 --> 00:07:17,890 ‫Oke, dan di sini di Postman, sekarang mari kita 149 00:07:19,060 --> 00:07:22,150 ‫ke rute yang sebenarnya ingin kita lindungi. 150 00:07:22,150 --> 00:07:24,270 ‫Dan kemudian di sini mengatur header. 151 00:07:24,270 --> 00:07:25,670 ‫Dan mari kita 152 00:07:29,100 --> 00:07:32,070 ‫lakukan tes satu dan atur ke jonas, oke? 153 00:07:32,070 --> 00:07:33,340 ‫Sekarang saya hanya akan 154 00:07:35,140 --> 00:07:38,240 ‫mengirim ini dan di sini di Express, mari kita lihat itu. 155 00:07:38,240 --> 00:07:41,800 ‫Dan memang di sini kita mendapatkan objek dengan semua header 156 00:07:41,800 --> 00:07:43,900 ‫yang merupakan bagian dari permintaan. 157 00:07:43,900 --> 00:07:45,700 ‫Jadi semua ini di sini. 158 00:07:45,700 --> 00:07:48,380 ‫Dan Anda lihat ada banyak header 159 00:07:48,380 --> 00:07:51,090 ‫yang dikirim oleh Postman secara otomatis bersama 160 00:07:51,090 --> 00:07:54,740 ‫dengan permintaan, misalnya, agen pengguna adalah Postman, ia juga 161 00:07:54,740 --> 00:07:56,970 ‫mengirim host, dan beberapa lainnya 162 00:07:56,970 --> 00:07:59,370 ‫yang akan kita bicarakan nanti seperti 163 00:07:59,370 --> 00:08:00,943 ‫menerima misalnya. 164 00:08:01,800 --> 00:08:04,070 ‫Nah yang penting disini sebenarnya header yang 165 00:08:04,070 --> 00:08:05,470 ‫kita atur sendiri. 166 00:08:05,470 --> 00:08:08,730 ‫Oke, jadi header pengujian disetel ke jonas yang baru saja 167 00:08:08,730 --> 00:08:10,360 ‫kami kirimkan dalam permintaan kami. 168 00:08:10,360 --> 00:08:14,240 ‫Sekarang untuk mengirim token web JSON sebagai header, sebenarnya 169 00:08:14,240 --> 00:08:16,470 ‫ada standar untuk melakukan itu. 170 00:08:16,470 --> 00:08:21,080 ‫Jadi mari kita kembali ke sini, singkirkan semua ini. 171 00:08:21,080 --> 00:08:24,760 ‫Dan standar untuk mengirim token adalah kita harus selalu 172 00:08:24,760 --> 00:08:27,503 ‫menggunakan header yang disebut otorisasi. 173 00:08:30,430 --> 00:08:31,263 ‫Oke? 174 00:08:31,263 --> 00:08:32,940 ‫Jadi seperti ini dan 175 00:08:32,940 --> 00:08:35,890 ‫kemudian nilai header itu harus selalu dimulai 176 00:08:35,890 --> 00:08:37,410 ‫dengan Bearer, oke? 177 00:08:37,410 --> 00:08:42,300 ‫Karena pada dasarnya kita menanggung, kita memiliki, kita memiliki token ini dan kemudian 178 00:08:42,300 --> 00:08:44,680 ‫di sini nilai dari token tersebut. 179 00:08:44,680 --> 00:08:47,750 ‫Jadi seperti string acak yang kita dapatkan sebelumnya. 180 00:08:47,750 --> 00:08:51,610 ‫Jadi biarkan saja dia di sini sebagai contoh, jadi mari 181 00:08:51,610 --> 00:08:53,323 ‫kita kirimkan itu sekarang. 182 00:08:55,180 --> 00:08:57,913 ‫Dan kemudian memang, kita harus mendapatkannya di sini. 183 00:08:59,050 --> 00:09:00,310 ‫Oke. 184 00:09:00,310 --> 00:09:03,620 ‫Sekarang Express kemudian secara otomatis mengubah semua nama header menjadi 185 00:09:03,620 --> 00:09:06,160 ‫huruf kecil, seperti yang Anda lihat 186 00:09:06,160 --> 00:09:09,950 ‫di sini, tetapi tentu saja, nilai header kami di sini masih sama. 187 00:09:09,950 --> 00:09:13,550 ‫Oke, dan pada dasarnya bagian dari nilai header ini 188 00:09:13,550 --> 00:09:15,050 ‫adalah token kita. 189 00:09:15,050 --> 00:09:16,870 ‫Dan begitulah seharusnya kita 190 00:09:16,870 --> 00:09:18,720 ‫sekarang membaca token itu dari header. 191 00:09:18,720 --> 00:09:19,553 ‫Baiklah? 192 00:09:20,550 --> 00:09:22,793 ‫Jadi jika sebenarnya 193 00:09:24,130 --> 00:09:29,130 ‫ada req. header. otorisasi, oke, dan 194 00:09:32,730 --> 00:09:34,300 ‫jika itu dimulai 195 00:09:34,300 --> 00:09:40,643 ‫pada dasarnya dengan string pembawa ini di sini oke, jadi 196 00:09:42,720 --> 00:09:46,670 ‫req. header. otorisasi dan sekarang 197 00:09:46,670 --> 00:09:48,240 ‫ini adalah string dan 198 00:09:48,240 --> 00:09:50,050 ‫jadi kita bisa menggunakan startWith 199 00:09:52,210 --> 00:09:55,290 ‫di sana oke, jadi ini JavaScript normal lagi 200 00:09:57,910 --> 00:09:58,930 ‫oke. 201 00:09:58,930 --> 00:10:03,020 ‫Jadi ini adalah kondisi di mana kita benar-benar 202 00:10:03,020 --> 00:10:05,430 ‫ingin menyimpan token, oke? 203 00:10:05,430 --> 00:10:08,530 ‫Jadi, sekali lagi, jika header 204 00:10:08,530 --> 00:10:13,260 ‫itu ada dan nilainya dimulai dengan Bearer, oke. 205 00:10:13,260 --> 00:10:18,260 ‫Kemudian dalam hal ini kami ingin mengatakan bahwa token sama 206 00:10:18,460 --> 00:10:22,257 ‫dengan req. header. otorisasi dan 207 00:10:23,890 --> 00:10:26,810 ‫sekarang bagaimana kita benar-benar mendapatkan bagian kedua 208 00:10:26,810 --> 00:10:28,350 ‫dari string ini? 209 00:10:28,350 --> 00:10:30,820 ‫Nah, pada dasarnya kita akan membagi string 210 00:10:30,820 --> 00:10:33,050 ‫dengan karakter spasi ini, oke, yang kemudian 211 00:10:33,050 --> 00:10:34,610 ‫akan membuat array dengan 212 00:10:34,610 --> 00:10:35,890 ‫Bearer ini 213 00:10:35,890 --> 00:10:37,860 ‫dan dengan token ini dan kemudian 214 00:10:37,860 --> 00:10:39,690 ‫kita akan mengambil bagian dari 215 00:10:39,690 --> 00:10:41,063 ‫array yang kita inginkan. 216 00:10:42,260 --> 00:10:45,080 ‫Jadi pisahkan menggunakan spasi, dan 217 00:10:45,080 --> 00:10:48,380 ‫kemudian dari array itu kita menginginkan elemen kedua. 218 00:10:48,380 --> 00:10:49,490 ‫Baiklah? 219 00:10:49,490 --> 00:10:52,760 ‫Sekarang kita tidak dapat benar-benar mendefinisikan variabel di dalam blok 220 00:10:52,760 --> 00:10:53,800 ‫if karena 221 00:10:53,800 --> 00:10:55,440 ‫const, dan let, sehingga 222 00:10:55,440 --> 00:10:58,260 ‫deklarasi variabel ES6 yang baru sebenarnya adalah cakupan 223 00:10:58,260 --> 00:10:59,710 ‫blok, dan jadi apa 224 00:10:59,710 --> 00:11:02,650 ‫pun yang kita definisikan di blok ini di 225 00:11:02,650 --> 00:11:04,700 ‫sini tidak akan tersedia di luarnya. 226 00:11:05,690 --> 00:11:08,643 ‫Oke, jadi mari kita lakukan itu di luar. 227 00:11:11,970 --> 00:11:16,280 ‫Dan kemudian cukup tetapkan kembali nilai ini ke token. 228 00:11:16,280 --> 00:11:17,113 ‫Oke. 229 00:11:18,670 --> 00:11:21,880 ‫Dan sekarang, mari kita log token ke konsol hanya 230 00:11:21,880 --> 00:11:23,863 ‫untuk melihat apakah itu berfungsi. 231 00:11:25,130 --> 00:11:28,670 ‫Oke, dan sebenarnya mari kita benar-benar mendapatkan token 232 00:11:28,670 --> 00:11:30,373 ‫nyata di sini. 233 00:11:31,240 --> 00:11:33,253 ‫Jadi yang baru saja kita masuki. 234 00:11:35,990 --> 00:11:39,710 ‫Dan kemudian letakkan yang itu di sini, baiklah. 235 00:11:39,710 --> 00:11:40,723 ‫Jadi 236 00:11:42,360 --> 00:11:45,480 ‫kirimkan, dan ah! 237 00:11:45,480 --> 00:11:45,480 ‫Ini dia. 238 00:11:45,480 --> 00:11:49,760 ‫Jadi di sini kami memiliki data token web JSON kami yang baru saja kami 239 00:11:49,760 --> 00:11:51,110 ‫kirim bersama dengan permintaan. 240 00:11:51,110 --> 00:11:55,120 ‫Langsung saja kita matikan console log ini disini. 241 00:11:55,120 --> 00:11:59,590 ‫Baiklah, dan sebelum kita melanjutkan, mari kita 242 00:11:59,590 --> 00:12:03,480 ‫periksa apakah token itu benar-benar ada. 243 00:12:03,480 --> 00:12:04,313 ‫Oke. 244 00:12:05,810 --> 00:12:07,510 ‫Jadi jika tidak ada 245 00:12:10,360 --> 00:12:14,090 ‫token yah, maka tentu kita ingin membuat error baru. 246 00:12:14,090 --> 00:12:16,630 ‫Benar, dan seperti sebelum kita 247 00:12:16,630 --> 00:12:19,030 ‫kembali dari middleware ini dan 248 00:12:19,030 --> 00:12:21,260 ‫memanggil yang berikutnya, oke. 249 00:12:21,260 --> 00:12:24,560 ‫Dan sekarang di sini, kita akan membuat kesalahan dan 250 00:12:24,560 --> 00:12:26,140 ‫kita akan langsung 251 00:12:26,140 --> 00:12:29,403 ‫beralih ke middleware penanganan kesalahan global dengan kesalahan ini. 252 00:12:30,487 --> 00:12:33,860 ‫Baiklah, jadi jika tidak ada token yang dikirim dengan permintaan, 253 00:12:33,860 --> 00:12:35,913 ‫itu berarti kita belum login. 254 00:12:36,870 --> 00:12:40,310 ‫Jadi mari kita kirim ke pengguna Anda tidak 255 00:12:41,530 --> 00:12:42,373 ‫masuk. 256 00:12:45,610 --> 00:12:48,793 ‫Silakan masuk untuk mendapatkan akses. 257 00:12:50,137 --> 00:12:52,380 ‫Baiklah, dan sekarang kode 258 00:12:52,380 --> 00:12:55,090 ‫status untuk situasi seperti ini adalah 259 00:12:55,090 --> 00:12:58,040 ‫401 yang artinya tidak sah, oke? 260 00:12:58,040 --> 00:13:00,430 ‫Tidak yakin apakah kami pernah menggunakan yang 261 00:13:00,430 --> 00:13:03,380 ‫itu sebelumnya dan ya, sebenarnya kami juga melakukannya di sini. 262 00:13:03,380 --> 00:13:05,290 ‫Oke, jadi ini pada 263 00:13:05,290 --> 00:13:08,890 ‫dasarnya berarti bahwa data yang dikirim dalam permintaan itu benar, 264 00:13:08,890 --> 00:13:12,110 ‫tetapi pada dasarnya data itu tidak cukup untuk mendapatkan 265 00:13:12,110 --> 00:13:15,050 ‫akses pengguna ke sumber daya yang dia minta. 266 00:13:15,050 --> 00:13:16,080 ‫Baiklah. 267 00:13:16,080 --> 00:13:17,280 ‫Simpan saja 268 00:13:18,280 --> 00:13:20,270 ‫di sini dan uji lagi. 269 00:13:20,270 --> 00:13:24,660 ‫Jadi, jika pada dasarnya kita menghilangkan header ini di sini, 270 00:13:24,660 --> 00:13:28,090 ‫maka kita harus langsung masuk ke kesalahan 271 00:13:28,090 --> 00:13:29,120 ‫itu, bukan? 272 00:13:29,120 --> 00:13:31,910 ‫Dan memang, Anda belum masuk, silakan masuk 273 00:13:31,910 --> 00:13:33,340 ‫untuk mendapatkan akses. 274 00:13:33,340 --> 00:13:35,600 ‫Dengan 401 tidak sah. 275 00:13:35,600 --> 00:13:38,950 ‫Besar! Jadi bagian itu sudah bekerja. 276 00:13:38,950 --> 00:13:41,500 ‫Baiklah, dan sekarang hanya untuk rekap, jadi 277 00:13:41,500 --> 00:13:44,590 ‫saat ini kami tidak mengirim token apa pun bersama 278 00:13:44,590 --> 00:13:45,903 ‫dengan permintaan, kan? 279 00:13:47,330 --> 00:13:51,370 ‫Dan karena alasan itu, tentu saja, tidak ada token, oke? 280 00:13:51,370 --> 00:13:53,380 ‫Dan karena itu kami membuat 281 00:13:53,380 --> 00:13:56,680 ‫kesalahan ini, yang kemudian akan memicu middleware penangan kesalahan kami 282 00:13:56,680 --> 00:13:59,260 ‫untuk mengirim kesalahan itu kembali ke klien, oke? 283 00:13:59,260 --> 00:14:02,690 ‫Dan tentu saja kita tidak mendapatkan akses 284 00:14:02,690 --> 00:14:05,600 ‫ke semua tur, karena tentu 285 00:14:05,600 --> 00:14:08,710 ‫saja middleware ini berjalan sebelum pengontrol getAllTours. 286 00:14:08,710 --> 00:14:13,070 ‫Dan sekarang, ini benar-benar dilindungi, oke? 287 00:14:13,070 --> 00:14:17,170 ‫Jadi itu benar-benar bekerja cukup bagus pada saat ini. 288 00:14:17,170 --> 00:14:19,870 ‫Tapi tentu saja, ini jauh dari 289 00:14:19,870 --> 00:14:23,480 ‫cukup, karena tidak cukup hanya mengirim token dengan permintaan. 290 00:14:23,480 --> 00:14:26,290 ‫Itu juga harus berupa token yang valid. 291 00:14:26,290 --> 00:14:28,410 ‫Jadi pada dasarnya token di mana tidak 292 00:14:28,410 --> 00:14:30,270 ‫ada yang mencoba mengubah muatannya. 293 00:14:30,270 --> 00:14:34,110 ‫Oke, dan payloadnya, ingat, dalam kasus 294 00:14:34,110 --> 00:14:39,110 ‫kami selalu user_id dari pengguna yang tokennya dikeluarkan. 295 00:14:39,210 --> 00:14:41,380 ‫Baiklah, dan selanjutnya 296 00:14:41,380 --> 00:14:44,200 ‫kita perlu menerapkan langkah verifikasi ini. 297 00:14:44,200 --> 00:14:47,160 ‫Tapi kuliah ini sudah berjalan cukup lama dan masih 298 00:14:47,160 --> 00:14:49,520 ‫banyak hal yang harus dilakukan di 299 00:14:49,520 --> 00:14:52,403 ‫sini, jadi mari kita tinggalkan itu untuk video berikutnya.