1
00:00:01,120 --> 00:00:02,370
‫Instruktur: Jadi dalam

2
00:00:02,370 --> 00:00:06,430
‫kuliah ini, kita akan mengelola kata sandi pengguna kita di database.

3
00:00:06,430 --> 00:00:08,790
‫Dan maksud saya untuk memvalidasi terlebih

4
00:00:08,790 --> 00:00:12,660
‫dahulu jika kata sandi yang dimasukkan sama dengan kata sandi

5
00:00:12,660 --> 00:00:16,380
‫yang dikonfirmasi dan kemudian juga mengenkripsi kata sandi dalam

6
00:00:16,380 --> 00:00:18,633
‫database untuk mengamankannya dari serangan.

7
00:00:20,320 --> 00:00:22,330
‫Dan hal pertama yang akan

8
00:00:22,330 --> 00:00:26,690
‫kita lakukan adalah memvalidasi apakah kedua kata sandi yang dimasukkan sama.

9
00:00:26,690 --> 00:00:28,840
‫Dan tempat terbaik untuk melakukannya

10
00:00:28,840 --> 00:00:31,760
‫adalah di sini di konfirmasi kata sandi, oke?

11
00:00:31,760 --> 00:00:36,283
‫Jadi mari kita tulis validator khusus kita untuk itu, oke?

12
00:00:38,480 --> 00:00:41,890
‫Jadi ingat, kita menggunakan properti validasi dan kemudian karena

13
00:00:41,890 --> 00:00:44,270
‫kita ingin membuat fungsi dan

14
00:00:44,270 --> 00:00:48,420
‫juga pesan kesalahan, mari kita buka objek baru di sini dan

15
00:00:49,480 --> 00:00:51,990
‫kemudian di sana buat validator, yang

16
00:00:51,990 --> 00:00:53,920
‫akan menjadi fungsi dan

17
00:00:53,920 --> 00:00:56,370
‫mari kita mulai dengan yang ini.

18
00:00:56,370 --> 00:00:58,780
‫Jadi, ingat, yang kita butuhkan di sini

19
00:00:58,780 --> 00:01:01,770
‫adalah menentukan fungsi panggilan balik sederhana yang kemudian akan

20
00:01:01,770 --> 00:01:03,853
‫dipanggil saat dokumen baru dibuat.

21
00:01:04,940 --> 00:01:06,163
‫Jadi, fungsi,

22
00:01:07,210 --> 00:01:10,320
‫dan sekali lagi, kita tidak dapat menggunakan fungsi panah

23
00:01:10,320 --> 00:01:13,183
‫karena kita sebenarnya perlu menggunakan kata kunci disk.

24
00:01:14,690 --> 00:01:15,523
‫Oke?

25
00:01:16,560 --> 00:01:19,180
‫Jadi, ingat bahwa dari fungsi validator kita

26
00:01:19,180 --> 00:01:21,470
‫mengembalikan true atau false

27
00:01:21,470 --> 00:01:23,960
‫dan jika nilai yang dikembalikan salah,

28
00:01:23,960 --> 00:01:27,550
‫maka itu berarti kita akan mendapatkan kesalahan validasi, oke?

29
00:01:27,550 --> 00:01:29,630
‫Dan, tentu saja, jika itu benar, maka tidak.

30
00:01:29,630 --> 00:01:33,820
‫Dan yang kami inginkan di sini adalah untuk mengatakan bahwa elemen saat

31
00:01:33,820 --> 00:01:37,643
‫ini jadi, konfirmasi kata sandi, sama dengan kata sandi titik ini,

32
00:01:37,643 --> 00:01:40,760
‫jadi, konfirmasi kata sandi, sama dengan kata sandi titik

33
00:01:40,760 --> 00:01:42,350
‫ini, dan hanya itu!

34
00:01:42,350 --> 00:01:46,510
‫Jadi, misalnya, jika konfirmasi kata sandi adalah A-B-C, dan

35
00:01:46,510 --> 00:01:49,520
‫kata sandi juga A-B-C, maka ini

36
00:01:49,520 --> 00:01:52,530
‫tentu saja akan mengembalikan benar, oke?

37
00:01:52,530 --> 00:01:54,330
‫Dan kemudian validasi dilewatkan

38
00:01:54,330 --> 00:01:56,550
‫dan tidak akan terjadi kesalahan.

39
00:01:56,550 --> 00:02:00,440
‫Tapi, jika kata sandi awal adalah, katakanlah, X-Y-Z, maka tentu

40
00:02:00,440 --> 00:02:02,860
‫saja ini akan mengembalikan false

41
00:02:02,860 --> 00:02:05,820
‫dan kita akan memiliki kesalahan validasi, oke?

42
00:02:05,820 --> 00:02:08,660
‫Jadi, sangat sederhana, tapi kita perlu

43
00:02:08,660 --> 00:02:12,320
‫ingat bahwa ini hanya akan berhasil di save, oke?

44
00:02:12,320 --> 00:02:13,950
‫Jadi saya membicarakannya

45
00:02:13,950 --> 00:02:17,840
‫sebelumnya ketika kami menggunakan validator khusus pada model tur, bukan?

46
00:02:17,840 --> 00:02:19,740
‫Tapi saya mengingatkan Anda

47
00:02:19,740 --> 00:02:24,120
‫tentang itu di sini lagi karena ini sangat penting di sini, oke?

48
00:02:24,120 --> 00:02:26,423
‫Jadi izinkan saya benar-benar menuliskannya di sini untuk Anda.

49
00:02:27,739 --> 00:02:30,410
‫(mengklik keyboard) Saat

50
00:02:30,410 --> 00:02:32,050
‫disimpan.

51
00:02:32,050 --> 00:02:32,883
‫Oke?

52
00:02:32,883 --> 00:02:35,740
‫Dan untuk alasan ini, setiap kali kami ingin memperbarui

53
00:02:35,740 --> 00:02:38,250
‫pengguna, kami harus selalu menggunakan simpan juga

54
00:02:38,250 --> 00:02:41,010
‫dan tidak, misalnya, menemukannya dan memperbarui seperti yang

55
00:02:41,010 --> 00:02:43,310
‫kami lakukan dengan tur kami, oke?

56
00:02:43,310 --> 00:02:45,570
‫Jadi mari kita ingat

57
00:02:45,570 --> 00:02:48,730
‫ini ketika kita menulis sisa kode di

58
00:02:48,730 --> 00:02:51,670
‫seluruh bagian dan terutama untuk memperbarui, oke?

59
00:02:51,670 --> 00:02:54,400
‫Karena misalkan kita mengupdate password pengguna

60
00:02:54,400 --> 00:02:56,320
‫hanya dengan update biasa.

61
00:02:56,320 --> 00:02:58,910
‫Maka dalam hal ini, kata sandi konfirmasi validasi

62
00:02:58,910 --> 00:03:01,540
‫yang kita miliki di sini tidak akan berfungsi lagi, oke?

63
00:03:01,540 --> 00:03:04,670
‫Dan tentu saja itu tidak boleh terjadi, oke?

64
00:03:04,670 --> 00:03:08,410
‫Jadi, sekali lagi, perlu diingat bahwa ini hanya akan

65
00:03:08,410 --> 00:03:12,920
‫berfungsi ketika kita membuat objek baru, seterusnya dot create, atau save.

66
00:03:12,920 --> 00:03:13,753
‫Oke?

67
00:03:13,753 --> 00:03:15,524
‫Jadi, saat membuat dan

68
00:03:15,524 --> 00:03:18,550
‫menyimpan, Jadi, saat membuat dan menyimpan,

69
00:03:18,550 --> 00:03:19,383
‫oke?

70
00:03:19,383 --> 00:03:22,830
‫Jadi kita membuat objek baru menggunakan create, kan?

71
00:03:22,830 --> 00:03:25,431
‫Jadi, di sini, menggunakan dot create Jadi, di

72
00:03:25,431 --> 00:03:27,100
‫sini, menggunakan dot create tapi

73
00:03:27,100 --> 00:03:28,463
‫ingat bagaimana saya

74
00:03:28,463 --> 00:03:31,143
‫juga menunjukkan kepada Anda bahwa kita dapat menggunakan

75
00:03:33,100 --> 00:03:35,160
‫pengguna dot save, seperti ini, kan?

76
00:03:35,160 --> 00:03:38,470
‫Dan sebenarnya, kita juga bisa menggunakan pengguna

77
00:03:38,470 --> 00:03:41,550
‫dot save untuk memperbarui pengguna, oke?

78
00:03:41,550 --> 00:03:43,593
‫Tetapi sekali lagi, lebih banyak tentang itu nanti.

79
00:03:44,820 --> 00:03:45,810
‫Oke?

80
00:03:45,810 --> 00:03:50,063
‫Jadi sekarang mari kita coba validasi ini di sini, oke?

81
00:03:51,230 --> 00:03:53,280
‫Jadi pertama-tama, mari kita coba membuat

82
00:03:53,280 --> 00:03:55,210
‫pengguna baru dengan data ini

83
00:03:55,210 --> 00:03:57,660
‫di sini yang seharusnya tidak berfungsi karena

84
00:03:57,660 --> 00:04:01,020
‫kami sudah memiliki pengguna dengan alamat email ini dan kami

85
00:04:01,020 --> 00:04:03,290
‫mengatakan bahwa yang ini harus unik dan

86
00:04:03,290 --> 00:04:04,590
‫seharusnya tidak berfungsi.

87
00:04:06,330 --> 00:04:12,210
‫Oke, dan tentu saja kesalahan kunci duplikat kami, bukan?

88
00:04:12,210 --> 00:04:14,170
‫Sekarang jika Anda sedang dalam produksi,

89
00:04:14,170 --> 00:04:17,040
‫maka tentu saja kita sudah akan mendapatkan kesalahan yang diformat

90
00:04:17,040 --> 00:04:19,620
‫dengan baik yang kita buat di bagian terakhir, bukan?

91
00:04:19,620 --> 00:04:23,730
‫Tetapi saat ini kami sedang dalam pengembangan dan itulah kesalahan yang kami definisikan

92
00:04:23,730 --> 00:04:25,383
‫yang ingin kami lihat.

93
00:04:26,510 --> 00:04:27,343
‫Oke?

94
00:04:28,440 --> 00:04:30,890
‫Jadi mari kita gunakan email lain di sini

95
00:04:30,890 --> 00:04:33,060
‫dan karena kita sedang mengerjakan email

96
00:04:33,060 --> 00:04:36,593
‫di sini, mari kita lihat juga cara kerja validasi alamat email.

97
00:04:37,650 --> 00:04:40,833
‫Jadi katakanlah kami menetapkan ini sebagai email kami.

98
00:04:42,190 --> 00:04:47,663
‫Jadi, kami melihat kesalahan, "harap berikan email yang valid. " Oke?

99
00:04:48,660 --> 00:04:51,320
‫Jadi mari kita uji seperti ini karena menurut

100
00:04:51,320 --> 00:04:53,120
‫saya ini juga tidak valid.

101
00:04:53,120 --> 00:04:55,043
‫Mungkin iya, tapi mari kita lihat.

102
00:04:56,170 --> 00:04:57,840
‫Dan ya, sebenarnya bukan karena

103
00:04:57,840 --> 00:05:01,050
‫tidak ada nama domain yang hanya memiliki satu huruf, oke?

104
00:05:01,050 --> 00:05:03,990
‫Jadi validator ini cukup spesifik

105
00:05:03,990 --> 00:05:05,890
‫sehingga sangat bagus.

106
00:05:05,890 --> 00:05:09,080
‫Sekarang jika kita melakukannya seperti ini, maka tentu saja itu harus berhasil.

107
00:05:09,080 --> 00:05:11,000
‫Tapi bagaimanapun, yang ingin kami uji

108
00:05:11,000 --> 00:05:13,860
‫di sini adalah kata sandi yang berbeda ini, oke?

109
00:05:13,860 --> 00:05:15,460
‫Dan saya ingat sekarang

110
00:05:15,460 --> 00:05:18,493
‫bahwa kami sebenarnya tidak membuat pesan kesalahan, saya percaya.

111
00:05:19,430 --> 00:05:21,070
‫Dan ya, kami tidak melakukannya.

112
00:05:21,070 --> 00:05:22,993
‫Jadi, mari tambahkan itu di sini juga.

113
00:05:25,120 --> 00:05:31,803
‫Jadi pesan, tidak sama.

114
00:05:32,900 --> 00:05:33,733
‫Oke.

115
00:05:35,580 --> 00:05:38,390
‫Jadi mari kita tambahkan sesuatu di sini, tidak masalah.

116
00:05:38,390 --> 00:05:42,613
‫Jadi sekarang, kata sandi tidak sama, oke?

117
00:05:43,460 --> 00:05:45,233
‫Begitu sempurna.

118
00:05:45,233 --> 00:05:48,333
‫Dan sekarang tentu saja validasi kita harus lolos.

119
00:05:49,640 --> 00:05:53,690
‫Dan memang, itu dan kami membuat pengguna baru kami.

120
00:05:53,690 --> 00:05:55,900
‫Mari menuju ke Kompas di

121
00:05:55,900 --> 00:05:58,640
‫sini, lihat, dan kemudian benar-benar menghapusnya sehingga

122
00:05:58,640 --> 00:06:02,953
‫nanti saya dapat membuat lebih banyak pengguna dengan email yang sama.

123
00:06:04,330 --> 00:06:05,163
‫Baiklah?

124
00:06:05,163 --> 00:06:07,310
‫Dan kami tidak ingin semua sampah ini

125
00:06:07,310 --> 00:06:09,990
‫ada di sini, jadi semua pengguna uji ini, oke?

126
00:06:09,990 --> 00:06:13,330
‫Tapi sekarang, langkah selanjutnya adalah mengenkripsi password

127
00:06:13,330 --> 00:06:15,560
‫biasa yang kita simpan di

128
00:06:15,560 --> 00:06:17,570
‫database kita sekarang.

129
00:06:17,570 --> 00:06:19,940
‫Jadi, seperti yang saya sebutkan di

130
00:06:19,940 --> 00:06:21,950
‫video terakhir, ketika kita

131
00:06:21,950 --> 00:06:24,220
‫bekerja dengan otentikasi, salah satu prinsip

132
00:06:24,220 --> 00:06:29,090
‫paling mendasar adalah jangan pernah menyimpan kata sandi biasa dalam database, oke?

133
00:06:29,090 --> 00:06:33,170
‫Jadi itu adalah sesuatu yang sama sekali tidak dapat diterima, oke?

134
00:06:33,170 --> 00:06:36,650
‫Jadi kita harus benar-benar selalu mengenkripsi kata sandi pengguna karena

135
00:06:36,650 --> 00:06:38,510
‫bayangkan untuk beberapa alasan,

136
00:06:38,510 --> 00:06:41,250
‫seorang peretas mendapatkan akses ke basis data.

137
00:06:41,250 --> 00:06:44,880
‫Jika kemudian kata sandi disimpan dalam teks biasa di sana, maka

138
00:06:44,880 --> 00:06:47,550
‫dia cukup masuk sebagai pengguna mana pun dan

139
00:06:47,550 --> 00:06:49,720
‫kemudian melakukan apa pun yang dia

140
00:06:49,720 --> 00:06:52,730
‫inginkan dan menyebabkan banyak kerusakan dalam beberapa kasus, oke?

141
00:06:52,730 --> 00:06:55,770
‫Jadi kita harus benar-benar mencegahnya.

142
00:06:55,770 --> 00:06:58,563
‫Jadi sekarang mari kita lanjutkan dan terapkan ini.

143
00:06:59,870 --> 00:07:03,610
‫Sekarang, di mana tempat terbaik untuk benar-benar melakukan itu?

144
00:07:03,610 --> 00:07:07,270
‫Yah, saya berpendapat bahwa model selalu merupakan tempat

145
00:07:07,270 --> 00:07:10,160
‫terbaik untuk melakukan fungsi semacam ini.

146
00:07:10,160 --> 00:07:12,110
‫Jadi dalam hal ini, enkripsi

147
00:07:12,110 --> 00:07:14,960
‫karena itu benar-benar ada hubungannya dengan data itu

148
00:07:14,960 --> 00:07:16,730
‫sendiri dan itu harus

149
00:07:16,730 --> 00:07:19,070
‫di model dan bukan di controller, oke?

150
00:07:19,070 --> 00:07:22,022
‫Jadi sekali lagi, ingatlah model gemuk, filosofi

151
00:07:22,022 --> 00:07:24,040
‫pengontrol tipis di sini.

152
00:07:24,040 --> 00:07:24,873
‫Baiklah?

153
00:07:27,260 --> 00:07:31,170
‫Jadi bagaimana kita sekarang akan menerapkan enkripsi ini?

154
00:07:31,170 --> 00:07:33,660
‫Nah, ini adalah kasus penggunaan sempurna

155
00:07:33,660 --> 00:07:36,050
‫lainnya untuk menggunakan middleware Mongoose.

156
00:07:36,050 --> 00:07:37,430
‫Dan salah satu yang

157
00:07:37,430 --> 00:07:39,210
‫akan kita gunakan adalah pre-save middleware.

158
00:07:39,210 --> 00:07:42,630
‫Jadi pada dasarnya mendokumentasikan middleware, oke?

159
00:07:42,630 --> 00:07:47,630
‫Jadi, ingat bahwa kita mendefinisikannya di skema, oke?

160
00:07:47,760 --> 00:07:50,130
‫Dan dalam hal ini, kami

161
00:07:50,130 --> 00:07:52,928
‫ingin mengatur pre-hook, jadi pre-middleware disimpan, oke?

162
00:07:52,928 --> 00:07:54,490
‫jadi pra-middleware di save, oke?

163
00:07:54,490 --> 00:07:56,750
‫Dan alasan mengapa kami melakukannya

164
00:07:56,750 --> 00:07:58,320
‫seperti ini adalah

165
00:07:58,320 --> 00:08:01,240
‫karena fungsi middleware yang akan kami tentukan

166
00:08:01,240 --> 00:08:03,660
‫di sini, jadi enkripsi, akan terjadi

167
00:08:03,660 --> 00:08:05,990
‫antara saat kami menerima data tersebut

168
00:08:05,990 --> 00:08:09,340
‫dan saat data tersebut disimpan ke basis data, oke?

169
00:08:09,340 --> 00:08:12,200
‫Jadi di situlah middleware pra-simpan berjalan.

170
00:08:12,200 --> 00:08:15,600
‫Antara mendapatkan data dan menyimpannya ke database.

171
00:08:15,600 --> 00:08:19,210
‫Dan itulah saat yang tepat untuk memanipulasi data.

172
00:08:19,210 --> 00:08:20,420
‫Baiklah?

173
00:08:20,420 --> 00:08:21,253
‫Jadi,

174
00:08:22,480 --> 00:08:26,010
‫sebuah fungsi, dan kemudian ingat kita memiliki

175
00:08:26,010 --> 00:08:29,740
‫akses ke fungsi berikutnya untuk memanggil middleware berikutnya.

176
00:08:29,740 --> 00:08:33,220
‫Oke, sekarang kita sebenarnya hanya ingin mengenkripsi

177
00:08:33,220 --> 00:08:37,400
‫kata sandi jika kolom kata sandi benar-benar telah diperbarui, oke?

178
00:08:37,400 --> 00:08:40,900
‫Jadi pada dasarnya hanya ketika benar-benar kata sandi diubah

179
00:08:40,900 --> 00:08:43,370
‫atau juga ketika dibuat baru, oke?

180
00:08:43,370 --> 00:08:46,890
‫Karena bayangkan pengguna hanya memperbarui email.

181
00:08:46,890 --> 00:08:48,340
‫Kemudian dalam hal

182
00:08:48,340 --> 00:08:51,760
‫ini, tentu kita tidak ingin mengenkripsi password lagi, bukan?

183
00:08:51,760 --> 00:08:54,420
‫Jadi kita bisa melakukannya dengan Mongoose.

184
00:08:54,420 --> 00:08:58,130
‫Jadi kita akan mengatakan, jika dan kemudian ini, yang

185
00:08:58,130 --> 00:09:00,840
‫mengacu pada dokumen saat ini, kan?

186
00:09:00,840 --> 00:09:03,070
‫Dan dalam hal ini, untuk pengguna saat

187
00:09:03,070 --> 00:09:04,583
‫ini dan kemudian dimodifikasi.

188
00:09:06,690 --> 00:09:07,523
‫Oke?

189
00:09:07,523 --> 00:09:10,670
‫Jadi kami memiliki metode pada semua dokumen yang dapat

190
00:09:10,670 --> 00:09:13,260
‫kami gunakan jika bidang tertentu telah dimodifikasi.

191
00:09:13,260 --> 00:09:16,270
‫Dan di sini, kita harus memasukkan nama bidang, jadi

192
00:09:16,270 --> 00:09:18,773
‫"kata sandi. " Oke?

193
00:09:18,773 --> 00:09:21,080
‫Jadi pada dasarnya, yang ingin kita lakukan

194
00:09:21,080 --> 00:09:24,440
‫di sini adalah mengatakan bahwa jika kata sandi belum diubah,

195
00:09:24,440 --> 00:09:27,540
‫jadi tidak, maka dalam hal ini, mari kita kembali

196
00:09:27,540 --> 00:09:30,520
‫dari fungsi ini dan tidak menjalankan kode lain apa

197
00:09:30,520 --> 00:09:32,320
‫pun yang ada di sini

198
00:09:33,160 --> 00:09:34,863
‫lalu panggil middleware berikutnya.

199
00:09:35,834 --> 00:09:36,667
‫Oke?

200
00:09:37,930 --> 00:09:41,170
‫Jadi sekali lagi, jika kata sandi belum diubah, maka

201
00:09:41,170 --> 00:09:42,810
‫keluar saja dari fungsi

202
00:09:42,810 --> 00:09:44,600
‫ini dan panggil middleware berikutnya.

203
00:09:44,600 --> 00:09:46,770
‫Jika tidak, kita akan menjalankan kode yang

204
00:09:46,770 --> 00:09:48,580
‫akan saya masukkan di sini.

205
00:09:48,580 --> 00:09:51,270
‫Jadi sekarang saatnya untuk benar-benar mengenkripsi,

206
00:09:51,270 --> 00:09:55,200
‫atau seperti yang bisa kita katakan, untuk meng-hash kata sandi, oke?

207
00:09:55,200 --> 00:09:58,490
‫Jadi Anda akan melihat istilah "hash" atau "hashing"

208
00:09:58,490 --> 00:10:01,890
‫sepanjang waktu dan itu pada dasarnya juga berarti enkripsi, oke?

209
00:10:01,890 --> 00:10:05,440
‫Sekarang kita akan melakukan enkripsi ini, atau

210
00:10:05,440 --> 00:10:08,580
‫hashing, menggunakan algoritma hashing yang

211
00:10:08,580 --> 00:10:13,230
‫sangat terkenal dan dipelajari dan sangat populer yang disebut bcrypt.

212
00:10:13,230 --> 00:10:14,290
‫Oke?

213
00:10:14,290 --> 00:10:18,200
‫Jadi algoritme ini pertama-tama akan memberi garam kemudian meng-hash

214
00:10:18,200 --> 00:10:21,130
‫kata sandi kita agar benar-benar kuat untuk

215
00:10:21,130 --> 00:10:23,760
‫melindunginya dari serangan bruteforce, oke?

216
00:10:23,760 --> 00:10:25,280
‫Dan itulah alasan

217
00:10:25,280 --> 00:10:27,600
‫mengapa enkripsi harus benar-benar kuat.

218
00:10:27,600 --> 00:10:30,360
‫Karena serangan bruteforce dapat mencoba menebak

219
00:10:30,360 --> 00:10:34,040
‫kata sandi tertentu jika tidak benar-benar kuat terenkripsi.

220
00:10:34,040 --> 00:10:37,990
‫Dan ingat bagaimana saya mengatakan bahwa bcrypt akan memberi garam kata sandi

221
00:10:37,990 --> 00:10:40,950
‫kita dan itu hanya berarti bahwa itu akan menambahkan

222
00:10:40,950 --> 00:10:44,500
‫string acak ke kata sandi sehingga dua kata sandi yang

223
00:10:44,500 --> 00:10:47,430
‫sama tidak menghasilkan hash yang sama, oke?

224
00:10:47,430 --> 00:10:48,490
‫Masuk akal?

225
00:10:48,490 --> 00:10:51,520
‫Sekarang saya tidak akan membahas semua detail kriptografi tentang bagaimana

226
00:10:51,520 --> 00:10:53,940
‫ini benar-benar bekerja di belakang layar

227
00:10:53,940 --> 00:10:56,850
‫dan mengapa kita membutuhkan sistem yang begitu rumit, oke?

228
00:10:56,850 --> 00:11:00,140
‫Tetapi tentu saja Anda dapat membaca semua yang Anda inginkan tentang bcrypt online.

229
00:11:00,140 --> 00:11:02,830
‫Benar-benar ada banyak hal menarik untuk

230
00:11:02,830 --> 00:11:05,290
‫ditemukan di sana, oke?

231
00:11:05,290 --> 00:11:09,270
‫Bagaimanapun, sekarang mari kita lanjutkan dan gunakan paket bcrypt

232
00:11:09,270 --> 00:11:12,133
‫js untuk menggunakan algoritma ini.

233
00:11:13,790 --> 00:11:14,623
‫Jadi, jadi

234
00:11:15,560 --> 00:11:16,393
‫npm install

235
00:11:16,393 --> 00:11:17,660
‫jadi npm install

236
00:11:19,156 --> 00:11:21,655
‫bcryptjs.

237
00:11:21,655 --> 00:11:22,488
‫Oke?

238
00:11:22,488 --> 00:11:25,410
‫Jadi ini pada dasarnya adalah implementasi bcrypt

239
00:11:25,410 --> 00:11:26,713
‫untuk Javascript.

240
00:11:27,650 --> 00:11:28,750
‫Oke?

241
00:11:28,750 --> 00:11:30,720
‫Mari kita kembali ke terminal utama kita

242
00:11:32,550 --> 00:11:34,513
‫lalu melanjutkan dan mengimpornya di sini.

243
00:11:36,092 --> 00:11:40,820
‫Dan yang ini secara default hanya disebut bcrypt, oke?

244
00:11:40,820 --> 00:11:41,873
‫Dan bukan bcryptjs.

245
00:11:42,889 --> 00:11:50,163
‫(mengklik keyboard) Baiklah.

246
00:11:53,360 --> 00:11:54,193
‫Baiklah.

247
00:11:54,193 --> 00:11:56,033
‫Dan sekarang, mari kita benar-benar menggunakannya.

248
00:11:56,970 --> 00:12:00,293
‫Jadi, kami ingin mengatakan bahwa kata sandi titik ini, jadi

249
00:12:01,370 --> 00:12:03,510
‫kata sandi saat ini dalam dokumen

250
00:12:04,590 --> 00:12:07,381
‫ini harus sama dengan bcrypt dot hash harus

251
00:12:07,381 --> 00:12:10,214
‫sama dengan bcrypt dot hash dan kemudian kata

252
00:12:11,600 --> 00:12:13,100
‫sandi kami saat ini.

253
00:12:14,640 --> 00:12:15,473
‫Oke?

254
00:12:15,473 --> 00:12:19,600
‫Dan kemudian di sini kita perlu menentukan parameter biaya, oke?

255
00:12:19,600 --> 00:12:22,100
‫Dan kita sebenarnya bisa melakukan ini dengan dua cara.

256
00:12:22,100 --> 00:12:25,700
‫Jadi cara pertama adalah menghasilkan garam secara manual, sehingga string

257
00:12:25,700 --> 00:12:27,740
‫acak pada dasarnya, yang akan ditambahkan

258
00:12:27,740 --> 00:12:29,727
‫ke kata sandi kita

259
00:12:29,727 --> 00:12:33,770
‫dan kemudian menggunakan garam itu di sini dalam fungsi hash ini.

260
00:12:33,770 --> 00:12:34,603
‫Baiklah?

261
00:12:34,603 --> 00:12:36,480
‫Namun sebaliknya, untuk membuatnya sedikit lebih

262
00:12:36,480 --> 00:12:39,260
‫mudah, kita juga dapat memasukkan parameter cost ke dalam

263
00:12:39,260 --> 00:12:40,620
‫fungsi ini di sini.

264
00:12:40,620 --> 00:12:42,920
‫Dan pada dasarnya itu

265
00:12:42,920 --> 00:12:47,360
‫adalah ukuran seberapa intensif CPU operasi ini, oke?

266
00:12:47,360 --> 00:12:50,230
‫Dan nilai default di sini saya percaya adalah

267
00:12:50,230 --> 00:12:53,130
‫10, tapi sekarang lebih baik menggunakan 12 karena

268
00:12:53,130 --> 00:12:55,810
‫komputer menjadi lebih dan lebih kuat.

269
00:12:55,810 --> 00:12:58,800
‫Jadi seperti 20 tahun yang lalu, Anda bisa menggunakan delapan di

270
00:12:58,800 --> 00:13:01,170
‫sini dan kemudian sedikit lebih lambat dari

271
00:13:01,170 --> 00:13:04,670
‫10, tetapi sekarang pada titik waktu ini, yang terbaik adalah menggunakan 12.

272
00:13:04,670 --> 00:13:06,610
‫Jadi semakin tinggi biaya

273
00:13:06,610 --> 00:13:09,610
‫ini di sini, pada dasarnya semakin intensif

274
00:13:09,610 --> 00:13:13,350
‫CPU prosesnya dan semakin baik kata sandinya akan dienkripsi, oke?

275
00:13:13,350 --> 00:13:15,070
‫Dan tentu saja kita bisa naik

276
00:13:15,070 --> 00:13:17,750
‫lebih tinggi lagi, tapi itu akan memakan waktu terlalu lama, oke?

277
00:13:17,750 --> 00:13:20,330
‫Dan saya akan menunjukkannya kepada Anda sebentar lagi.

278
00:13:20,330 --> 00:13:21,163
‫Oke?

279
00:13:21,163 --> 00:13:22,910
‫Tapi untuk saat ini, mari

280
00:13:22,910 --> 00:13:26,060
‫kita selesaikan ini karena ada satu hal yang tersisa di sini.

281
00:13:26,060 --> 00:13:29,040
‫Jadi hash ini di sini sebenarnya versi asynchronous,

282
00:13:29,040 --> 00:13:31,440
‫tapi ada juga versi synchronous.

283
00:13:31,440 --> 00:13:33,960
‫Tetapi seperti yang sudah Anda ketahui, kami

284
00:13:33,960 --> 00:13:35,313
‫tidak ingin menggunakan

285
00:13:35,313 --> 00:13:38,810
‫versi sinkron karena itu akan memblokir loop acara dan kemudian

286
00:13:38,810 --> 00:13:41,000
‫mencegah pengguna lain menggunakan aplikasi.

287
00:13:41,000 --> 00:13:43,350
‫Jadi seperti yang kita pelajari di awal.

288
00:13:43,350 --> 00:13:45,230
‫Dan tentu saja

289
00:13:45,230 --> 00:13:48,130
‫kami ingin menggunakan versi asinkron yang ini.

290
00:13:48,130 --> 00:13:50,210
‫Dan ini kemudian akan mengembalikan

291
00:13:50,210 --> 00:13:53,860
‫janji dan janji itu, tentu saja, perlu kita tunggu.

292
00:13:53,860 --> 00:13:58,860
‫Jadi, kita perlu menggunakan menunggu dan kemudian mengatakan bahwa fungsi

293
00:13:58,960 --> 00:14:02,513
‫ini adalah fungsi async, seperti ini.

294
00:14:04,730 --> 00:14:06,860
‫Jadi, mari kita rekap itu di sini.

295
00:14:06,860 --> 00:14:09,780
‫Jadi, kami ingin mengatur kata sandi kami

296
00:14:09,780 --> 00:14:14,780
‫saat ini pada dasarnya untuk mengenkripsi versi kata sandi asli ini dengan

297
00:14:14,780 --> 00:14:17,500
‫biaya 12, tidak membuatnya terlalu

298
00:14:17,500 --> 00:14:21,690
‫mudah untuk memecahkan kata sandi, tetapi juga tidak membuat

299
00:14:21,690 --> 00:14:25,423
‫aplikasi terlalu lama untuk mengenkripsi kata sandi, Baiklah?

300
00:14:25,423 --> 00:14:27,920
‫Jadi dengan ini, kami mengenkripsi kata sandi

301
00:14:27,920 --> 00:14:30,070
‫kami dan sekarang pada akhirnya,

302
00:14:30,070 --> 00:14:33,840
‫yang perlu kami lakukan adalah menghapus kata sandi konfirmasi, oke?

303
00:14:33,840 --> 00:14:35,670
‫Karena pada saat ini,

304
00:14:35,670 --> 00:14:38,663
‫kami hanya memiliki hash kata sandi yang sebenarnya, bukan?

305
00:14:40,560 --> 00:14:42,489
‫Jadi, kata sandi titik ini

306
00:14:42,489 --> 00:14:43,643
‫mengkonfirmasi, Jadi,

307
00:14:43,643 --> 00:14:45,980
‫kata sandi titik ini mengkonfirmasi, dan bagaimana

308
00:14:45,980 --> 00:14:48,740
‫kami pada dasarnya menghapus bidang, agar tidak bertahan

309
00:14:48,740 --> 00:14:51,440
‫dalam database adalah dengan mengaturnya ke tidak terdefinisi.

310
00:14:51,440 --> 00:14:52,400
‫Baiklah?

311
00:14:52,400 --> 00:14:55,970
‫Jadi, kita benar-benar hanya membutuhkan konfirmasi kata sandi ini di

312
00:14:55,970 --> 00:14:58,950
‫sini untuk validasi yang telah kita terapkan sebelumnya.

313
00:14:58,950 --> 00:15:00,730
‫Jadi hanya untuk memastikan

314
00:15:00,730 --> 00:15:03,160
‫bahwa pengguna benar-benar memasukkan dua kata sandi

315
00:15:03,160 --> 00:15:06,660
‫yang sama sehingga dia tidak membuat kesalahan dengan kata sandinya.

316
00:15:06,660 --> 00:15:07,590
‫Benar?

317
00:15:07,590 --> 00:15:10,300
‫Dan setelah validasi ini berhasil,

318
00:15:10,300 --> 00:15:13,060
‫kami sebenarnya tidak lagi membutuhkan bidang

319
00:15:13,060 --> 00:15:16,710
‫ini sehingga kami benar-benar tidak ingin menyimpannya ke database.

320
00:15:16,710 --> 00:15:20,130
‫Dan itulah mengapa kami mengaturnya di sini menjadi tidak terdefinisi.

321
00:15:20,130 --> 00:15:21,150
‫Baiklah?

322
00:15:21,150 --> 00:15:23,220
‫Sekarang Anda mungkin bertanya-tanya mengapa ini

323
00:15:23,220 --> 00:15:25,920
‫berhasil karena kami benar-benar menetapkan konfirmasi kata sandi

324
00:15:25,920 --> 00:15:27,800
‫ke yang diperlukan, bukan?

325
00:15:27,800 --> 00:15:30,750
‫Tapi itu berarti bahwa itu adalah input yang

326
00:15:30,750 --> 00:15:33,650
‫diperlukan, bukan berarti itu harus benar-benar disimpan

327
00:15:33,650 --> 00:15:36,982
‫ke database, oke?

328
00:15:38,393 --> 00:15:42,390
‫Sekarang, hanya untuk menyelesaikan, kita tentu perlu juga menelepon berikutnya.

329
00:15:42,390 --> 00:15:43,240
‫Oke?

330
00:15:43,240 --> 00:15:44,290
‫Mari kita simpan.

331
00:15:45,640 --> 00:15:47,440
‫Dan sebenarnya saya akan menambahkan beberapa komentar

332
00:15:47,440 --> 00:15:49,370
‫di sini untuk membuatnya sangat jelas bagi Anda.

333
00:15:49,370 --> 00:15:52,400
‫Jadi pada dasarnya apa yang dilakukannya, adalah hanya

334
00:15:54,180 --> 00:15:55,050
‫menjalankan

335
00:15:56,160 --> 00:15:57,190
‫fungsi ini jika

336
00:15:58,930 --> 00:16:00,533
‫kata sandi benar-benar diubah.

337
00:16:05,070 --> 00:16:05,903
‫Lalu

338
00:16:08,840 --> 00:16:11,803
‫di sini, hash kata sandi dengan biaya 12.

339
00:16:14,785 --> 00:16:16,300
‫Dan kemudian,

340
00:16:16,300 --> 00:16:19,443
‫hapus bidang konfirmasi kata sandi.

341
00:16:20,750 --> 00:16:21,583
‫Oke.

342
00:16:21,583 --> 00:16:24,453
‫Dan sekarang, mari kita lanjutkan dan uji ini.

343
00:16:25,660 --> 00:16:29,590
‫Dan sekarang saya akan membuat pengguna baru dengan data ini

344
00:16:29,590 --> 00:16:32,470
‫dan sekarang mari kita lihat hasilnya.

345
00:16:32,470 --> 00:16:36,460
‫Dan memang, kami sekarang mendapatkan kata sandi yang tampak sangat

346
00:16:36,460 --> 00:16:40,163
‫aneh ini yang memang merupakan versi terenkripsi dari pass1234.

347
00:16:41,410 --> 00:16:45,580
‫Dan juga, seperti yang Anda lihat, konfirmasi kata sandi tidak lagi ada di sini.

348
00:16:45,580 --> 00:16:46,413
‫Oke?

349
00:16:46,413 --> 00:16:48,930
‫Jadi seperti ini, kami sekarang menyimpan pengguna dengan

350
00:16:48,930 --> 00:16:51,353
‫cara yang aman di database kami.

351
00:16:52,280 --> 00:16:55,310
‫Sekarang saya akan menunjukkan cara kerjanya jika kita,

352
00:16:55,310 --> 00:16:58,233
‫misalnya, menyetelnya ke 16 di sini.

353
00:17:00,740 --> 00:17:02,540
‫Dan saya perlu mengubah email di sini.

354
00:17:03,540 --> 00:17:07,120
‫Dan itu sekarang membutuhkan banyak waktu dan saya tidak

355
00:17:07,120 --> 00:17:09,180
‫yakin apakah saya bisa menunggu.

356
00:17:09,180 --> 00:17:12,490
‫Oh, sebenarnya butuh empat setengah detik.

357
00:17:12,490 --> 00:17:17,320
‫Tapi itu masih agak terlalu banyak saya percaya, oke?

358
00:17:17,320 --> 00:17:18,980
‫Jadi, mari kita

359
00:17:18,980 --> 00:17:20,330
‫atur kembali

360
00:17:21,410 --> 00:17:24,507
‫ke 12 dan seharusnya lebih baik, oke?

361
00:17:24,507 --> 00:17:26,670
‫Dan sekarang mari, sekali lagi, hapus

362
00:17:26,670 --> 00:17:29,630
‫pengguna ini di sini yang baru saja kita buat.

363
00:17:29,630 --> 00:17:32,110
‫Dan sebenarnya saya harus menyingkirkan yang pertama

364
00:17:32,110 --> 00:17:36,000
‫ini karena yang ini masih memiliki kata sandi dalam teks biasa.

365
00:17:36,000 --> 00:17:38,090
‫Jadi pengguna ini tidak

366
00:17:38,090 --> 00:17:40,370
‫akan berfungsi saat kita mulai benar-benar

367
00:17:40,370 --> 00:17:42,621
‫memasukkan pengguna berdasarkan kata sandi mereka.

368
00:17:42,621 --> 00:17:44,250
‫Oke?

369
00:17:44,250 --> 00:17:45,743
‫Jadi mari kita singkirkan ini.

370
00:17:52,780 --> 00:17:54,060
‫Oke?

371
00:17:54,060 --> 00:17:56,170
‫Dan juga yang ingin saya tunjukkan di

372
00:17:57,510 --> 00:17:59,880
‫sini adalah bahwa kami memasukkan kata sandi yang sama

373
00:17:59,880 --> 00:18:02,390
‫persis untuk dua pengguna yang kami buat ini, bukan?

374
00:18:02,390 --> 00:18:04,520
‫Tetapi Anda melihat bahwa

375
00:18:04,520 --> 00:18:07,630
‫kata sandi terenkripsi sebenarnya sangat berbeda, bukan?

376
00:18:07,630 --> 00:18:09,820
‫Dan itulah kekuatan mengasinkan kata sandi

377
00:18:09,820 --> 00:18:11,043
‫sebelum melakukan hashing.

378
00:18:12,220 --> 00:18:13,060
‫Baiklah?

379
00:18:13,060 --> 00:18:17,250
‫Jadi seperti ini, kami, sekali lagi, menerapkan manajemen kata sandi yang

380
00:18:17,250 --> 00:18:19,313
‫sangat aman dan baik.