1 00:00:01,040 --> 00:00:03,970 ‫Narrador: Até agora, em nossa implementação 2 00:00:03,970 --> 00:00:07,780 ‫de autenticação, registramos os usuários com uma senha correta. 3 00:00:07,780 --> 00:00:11,170 ‫Então, basicamente, concluímos esta primeira etapa do fluxo de trabalho 4 00:00:11,170 --> 00:00:13,170 ‫de autenticação, em que 5 00:00:13,170 --> 00:00:15,760 ‫um token da web JSON é criado 6 00:00:15,760 --> 00:00:18,730 ‫e enviado de volta ao cliente se o 7 00:00:18,730 --> 00:00:21,440 ‫usuário fornecer um e-mail e uma senha corretos. 8 00:00:21,440 --> 00:00:25,350 ‫Então, a seguir, implementaremos rotas protegidas. 9 00:00:25,350 --> 00:00:28,630 ‫Basicamente, usando o token da Web JSON 10 00:00:28,630 --> 00:00:32,930 ‫criado para dar aos usuários logados acesso a rotas protegidas. 11 00:00:32,930 --> 00:00:36,220 ‫E esta é a segunda etapa da autenticação. 12 00:00:36,220 --> 00:00:39,823 ‫E agora vamos implementar essa funcionalidade. 13 00:00:41,620 --> 00:00:43,880 ‫Digamos que desejamos proteger 14 00:00:43,880 --> 00:00:45,670 ‫a rota getAllTours. 15 00:00:45,670 --> 00:00:48,470 ‫Então, basicamente, apenas permitindo que usuários logados tenham 16 00:00:48,470 --> 00:00:51,560 ‫acesso a uma lista de todos os nossos passeios. 17 00:00:51,560 --> 00:00:53,830 ‫E o que significa é que, antes de 18 00:00:53,830 --> 00:00:55,700 ‫executar o manipulador get all tours, 19 00:00:55,700 --> 00:00:57,353 ‫vamos dar uma olhada nisso. 20 00:00:58,340 --> 00:01:01,330 ‫Ok, então antes de executar este identificador aqui, 21 00:01:01,330 --> 00:01:03,240 ‫precisaríamos fazer uma verificação para 22 00:01:03,240 --> 00:01:05,120 ‫verificar se o 23 00:01:05,120 --> 00:01:07,760 ‫usuário está realmente logado ou não, certo? 24 00:01:07,760 --> 00:01:09,540 ‫E então a melhor 25 00:01:09,540 --> 00:01:11,640 ‫maneira de fazer isso, como você 26 00:01:11,640 --> 00:01:15,160 ‫já sabe, provavelmente, é usar uma função de middleware, certo? 27 00:01:15,160 --> 00:01:17,300 ‫Então, neste vídeo, para proteger 28 00:01:17,300 --> 00:01:19,640 ‫as rotas, vamos criar uma função de 29 00:01:19,640 --> 00:01:23,560 ‫middleware que será executada antes de cada um desses manipuladores, ok. 30 00:01:23,560 --> 00:01:26,320 ‫Então, uma função que ficará bem aqui, 31 00:01:26,320 --> 00:01:29,440 ‫antes que esta função aqui possa ser executada. 32 00:01:29,440 --> 00:01:32,050 ‫E esse middleware irá retornar um erro 33 00:01:32,050 --> 00:01:34,140 ‫se o usuário não estiver autenticado, 34 00:01:34,140 --> 00:01:35,850 ‫então, se ele 35 00:01:35,850 --> 00:01:37,780 ‫não estiver logado, ou irá 36 00:01:37,780 --> 00:01:42,150 ‫chamar o próximo middleware que neste caso é o manipulador getAllTours, certo? 37 00:01:42,150 --> 00:01:44,730 ‫E que do que eficaz protege esta 38 00:01:44,730 --> 00:01:47,080 ‫rota de acessos não autorizados. 39 00:01:47,080 --> 00:01:48,810 ‫Portanto, vamos criar rapidamente essa 40 00:01:48,810 --> 00:01:50,290 ‫função de middleware e 41 00:01:50,290 --> 00:01:51,480 ‫colocá-la aqui 42 00:01:51,480 --> 00:01:54,060 ‫para ilustrar o que acabei de dizer. 43 00:01:54,060 --> 00:01:57,620 ‫Ok, então aqui em nosso controlador de autenticação novamente, 44 00:01:57,620 --> 00:02:00,170 ‫criaremos uma nova função de middleware 45 00:02:03,920 --> 00:02:06,283 ‫e é chamada de proteger. 46 00:02:08,510 --> 00:02:09,343 ‫Tudo bem, 47 00:02:09,343 --> 00:02:11,600 ‫e assim como antes, vou usar catchAsync 48 00:02:12,480 --> 00:02:14,740 ‫porque, mais uma vez, todas essas funções 49 00:02:14,740 --> 00:02:16,553 ‫são funções assíncronas, na verdade. 50 00:02:17,990 --> 00:02:21,210 ‫Tudo bem, e aqui, é claro, nossa função de 51 00:02:24,320 --> 00:02:27,270 ‫middleware e, por enquanto, vamos simplesmente chamar next 52 00:02:27,270 --> 00:02:30,190 ‫aqui apenas para que tenhamos realmente qualquer corpo 53 00:02:30,190 --> 00:02:32,240 ‫aqui nesta função de 54 00:02:32,240 --> 00:02:35,090 ‫middleware e, em seguida, vamos voltar às 55 00:02:35,090 --> 00:02:38,540 ‫nossas rotas de passeio e proteger essa rota, ok ? 56 00:02:38,540 --> 00:02:42,190 ‫Portanto, antes de mais nada, preciso realmente exigir 57 00:02:42,190 --> 00:02:44,620 ‫este módulo controlador de autenticação. 58 00:02:44,620 --> 00:02:45,453 ‫Então 59 00:02:50,550 --> 00:02:52,350 ‫const e, em seguida, requer 60 00:02:56,410 --> 00:02:57,920 ‫que esteja nos controladores 61 00:02:57,920 --> 00:02:59,713 ‫e, em seguida, authController, ok. 62 00:03:01,430 --> 00:03:04,150 ‫Então, agora vamos conectá-lo, 63 00:03:04,150 --> 00:03:07,460 ‫bem aqui na rota getAllTours. 64 00:03:07,460 --> 00:03:08,293 ‫OK. 65 00:03:09,550 --> 00:03:13,913 ‫Portanto, authController. proteger. 66 00:03:14,860 --> 00:03:15,693 ‫OK. 67 00:03:15,693 --> 00:03:18,740 ‫E agora esta função de middleware será executada primeiro 68 00:03:18,740 --> 00:03:21,875 ‫e novamente, se o usuário não for autenticado, haverá 69 00:03:21,875 --> 00:03:22,950 ‫um erro. 70 00:03:22,950 --> 00:03:25,070 ‫E, claro, o próximo middleware para 71 00:03:25,070 --> 00:03:26,690 ‫que aquele que 72 00:03:26,690 --> 00:03:30,540 ‫realmente recebe e envia todos os tours não seja executado. 73 00:03:30,540 --> 00:03:31,373 ‫OK. 74 00:03:31,373 --> 00:03:34,700 ‫E, novamente, isso protegerá efetivamente o acesso 75 00:03:34,700 --> 00:03:38,223 ‫a este recurso de usuários que não estão logados. 76 00:03:39,250 --> 00:03:42,700 ‫Tudo bem, então vamos voltar aqui. 77 00:03:42,700 --> 00:03:44,340 ‫Não as rotas do 78 00:03:44,340 --> 00:03:45,993 ‫usuário, mas o controlador de autenticação. 79 00:03:46,850 --> 00:03:49,760 ‫Tudo bem, e agora sobre a implementação desse 80 00:03:49,760 --> 00:03:51,180 ‫middleware de proteção. 81 00:03:51,180 --> 00:03:53,660 ‫O que exatamente teremos que fazer? 82 00:03:53,660 --> 00:03:56,583 ‫Bem, vamos começar delineando algumas etapas aqui. 83 00:03:57,460 --> 00:04:00,660 ‫Tudo bem, na verdade, primeiro de tudo, precisamos marcar 84 00:04:00,660 --> 00:04:03,720 ‫essa função como Async, caso contrário, não precisaríamos 85 00:04:03,720 --> 00:04:05,630 ‫realmente do catchAsync, certo? 86 00:04:05,630 --> 00:04:09,260 ‫E você verá por que precisamos que isso seja uma função 87 00:04:09,260 --> 00:04:11,360 ‫Async em um segundo, certo? 88 00:04:11,360 --> 00:04:13,760 ‫Mas agora vamos definir as etapas 89 00:04:13,760 --> 00:04:16,803 ‫que precisamos seguir para implementar esse middleware de proteção. 90 00:04:18,460 --> 00:04:19,840 ‫Assim como antes, 91 00:04:19,840 --> 00:04:21,990 ‫vou colocar essas etapas aqui como comentários. 92 00:04:23,340 --> 00:04:26,173 ‫Primeiro, precisamos realmente obter o token. 93 00:04:28,720 --> 00:04:29,553 ‫E 94 00:04:30,660 --> 00:04:32,610 ‫verifique se ele está lá basicamente, 95 00:04:32,610 --> 00:04:34,303 ‫então verifique se ele existe. 96 00:04:35,400 --> 00:04:39,113 ‫Em seguida, precisamos validar o token. 97 00:04:41,860 --> 00:04:44,383 ‫E esta é basicamente aquela etapa 98 00:04:44,383 --> 00:04:48,900 ‫superimportante da qual falamos antes, em que o algoritmo JWT verifica se 99 00:04:48,900 --> 00:04:50,680 ‫a assinatura é válida ou 100 00:04:50,680 --> 00:04:51,513 ‫não. 101 00:04:51,513 --> 00:04:54,950 ‫Portanto, se o token é válido ou não, certo? 102 00:04:54,950 --> 00:04:57,450 ‫E então vamos chamar isso de verificação. 103 00:04:58,930 --> 00:05:01,680 ‫Acho que é assim que chamamos naquele slide onde 104 00:05:01,680 --> 00:05:03,630 ‫falamos sobre isso antes, tudo bem. 105 00:05:03,630 --> 00:05:06,040 ‫E se você realmente não se lembra como 106 00:05:06,040 --> 00:05:07,350 ‫funcionou, bem, você 107 00:05:07,350 --> 00:05:10,003 ‫sempre pode voltar e assistir a essa palestra, certo? 108 00:05:11,470 --> 00:05:15,750 ‫Em seguida, se a verificação foi realmente bem-sucedida, também precisamos 109 00:05:15,750 --> 00:05:18,930 ‫verificar se o usuário que está tentando 110 00:05:18,930 --> 00:05:21,870 ‫acessar a rota ainda existe, certo? 111 00:05:21,870 --> 00:05:25,940 ‫Portanto, verifique se o usuário ainda existe e falarei mais 112 00:05:25,940 --> 00:05:28,090 ‫sobre por que cada 113 00:05:28,090 --> 00:05:32,610 ‫uma dessas etapas é necessária assim que começarmos a implementá-las, certo? 114 00:05:32,610 --> 00:05:35,410 ‫Portanto, por enquanto, isso pode não fazer muito sentido 115 00:05:35,410 --> 00:05:38,950 ‫para você, mas, novamente, falarei sobre cada parada assim que chegarmos lá. 116 00:05:38,950 --> 00:05:39,783 ‫Tudo bem? 117 00:05:39,783 --> 00:05:41,440 ‫E, por fim, também precisamos 118 00:05:42,980 --> 00:05:43,813 ‫verificar 119 00:05:45,490 --> 00:05:47,000 ‫se o usuário alterou 120 00:05:50,090 --> 00:05:51,720 ‫a senha após o 121 00:05:53,060 --> 00:05:54,993 ‫JWT ter sido emitido, certo? 122 00:05:56,690 --> 00:05:58,280 ‫Bem, vamos apenas dizer token aqui, 123 00:05:58,280 --> 00:06:01,060 ‫nós o chamamos de token em todos os outros lugares, certo? 124 00:06:01,060 --> 00:06:03,320 ‫E assim, somente se não houver problemas 125 00:06:03,320 --> 00:06:05,310 ‫em qualquer uma dessas etapas 126 00:06:05,310 --> 00:06:08,480 ‫aqui, só então é claro que o próximo será chamado, 127 00:06:08,480 --> 00:06:11,210 ‫o que terá acesso à rota que protegemos. 128 00:06:11,210 --> 00:06:16,210 ‫Portanto, em nosso exemplo atual, novamente, este manipulador getAllTours. 129 00:06:16,420 --> 00:06:17,610 ‫Direito? 130 00:06:17,610 --> 00:06:19,260 ‫Ok, mas vamos voltar 131 00:06:19,260 --> 00:06:22,540 ‫e começar a implementar nossa primeira etapa aqui. 132 00:06:22,540 --> 00:06:24,380 ‫Então, basicamente pegue o 133 00:06:24,380 --> 00:06:26,860 ‫token e verifique se ele realmente existe. 134 00:06:26,860 --> 00:06:31,340 ‫Portanto, uma prática comum é enviar um token usando um cabeçalho 135 00:06:31,340 --> 00:06:33,380 ‫http com a solicitação, certo? 136 00:06:33,380 --> 00:06:36,580 ‫Então, vamos dar uma olhada em como podemos definir cabeçalhos no 137 00:06:36,580 --> 00:06:38,427 ‫Postman para enviá-lo junto com 138 00:06:38,427 --> 00:06:40,420 ‫a solicitação e também como podemos obter 139 00:06:40,420 --> 00:06:42,410 ‫acesso a esses cabeçalhos no Express. 140 00:06:42,410 --> 00:06:45,300 ‫E vamos fazer isso primeiro. 141 00:06:45,300 --> 00:06:50,300 ‫Então, aqui no apt. js Acho que temos este bom 142 00:06:51,240 --> 00:06:54,610 ‫middleware aqui, então vamos realmente fazer o login 143 00:06:56,290 --> 00:06:59,890 ‫na solicitação do console. cabeçalhos, Ok, então 144 00:06:59,890 --> 00:07:03,250 ‫falamos sobre cabeçalhos http antes, e é 145 00:07:03,250 --> 00:07:07,140 ‫assim que podemos ter acesso a eles no Express. 146 00:07:07,140 --> 00:07:10,350 ‫Ok, basicamente para os cabeçalhos de solicitação, aqueles 147 00:07:10,350 --> 00:07:13,753 ‫que um cliente pode enviar junto com sua solicitação. 148 00:07:14,600 --> 00:07:17,890 ‫Ok, e aqui no Postman, vamos realmente chegar 149 00:07:19,060 --> 00:07:22,150 ‫à rota que estamos tentando proteger. 150 00:07:22,150 --> 00:07:24,270 ‫E aqui defina um cabeçalho. 151 00:07:24,270 --> 00:07:25,670 ‫E vamos apenas 152 00:07:29,100 --> 00:07:32,070 ‫fazer um teste e configurá-lo para Jonas, ok? 153 00:07:32,070 --> 00:07:33,340 ‫Agora vou apenas enviar 154 00:07:35,140 --> 00:07:38,240 ‫isso e aqui no Express, vamos dar uma olhada nisso. 155 00:07:38,240 --> 00:07:41,800 ‫E, de fato, aqui obtemos um objeto com todos os cabeçalhos 156 00:07:41,800 --> 00:07:43,900 ‫que fazem parte da solicitação. 157 00:07:43,900 --> 00:07:45,700 ‫Então, tudo isso aqui. 158 00:07:45,700 --> 00:07:48,380 ‫E você vê que há um monte de cabeçalhos 159 00:07:48,380 --> 00:07:51,090 ‫que o Postman envia automaticamente junto com a solicitação, 160 00:07:51,090 --> 00:07:54,740 ‫por exemplo, ele diz que o agente do usuário é o Postman, 161 00:07:54,740 --> 00:07:56,970 ‫ele também envia o host, e alguns 162 00:07:56,970 --> 00:07:59,370 ‫outros sobre os quais falaremos mais tarde, 163 00:07:59,370 --> 00:08:00,943 ‫como aceitar por exemplo. 164 00:08:01,800 --> 00:08:04,070 ‫Agora, o que importa aqui é o cabeçalho que 165 00:08:04,070 --> 00:08:05,470 ‫definimos para nós mesmos. 166 00:08:05,470 --> 00:08:08,730 ‫Ok, então o cabeçalho de teste definido como Jonas que acabamos 167 00:08:08,730 --> 00:08:10,360 ‫de enviar em nossa solicitação. 168 00:08:10,360 --> 00:08:14,240 ‫Agora, para enviar um token da web JSON como cabeçalho, existe 169 00:08:14,240 --> 00:08:16,470 ‫um padrão para fazer isso. 170 00:08:16,470 --> 00:08:21,080 ‫Então vamos voltar aqui, nos livrar de tudo isso. 171 00:08:21,080 --> 00:08:24,760 ‫E então esse padrão para enviar um token é que 172 00:08:24,760 --> 00:08:27,503 ‫devemos sempre usar um cabeçalho chamado autorização. 173 00:08:30,430 --> 00:08:31,263 ‫OK? 174 00:08:31,263 --> 00:08:32,940 ‫Assim, o valor 175 00:08:32,940 --> 00:08:35,890 ‫desse cabeçalho deve sempre começar com 176 00:08:35,890 --> 00:08:37,410 ‫Bearer, certo? 177 00:08:37,410 --> 00:08:42,300 ‫Porque basicamente carregamos, possuímos, possuímos esse token e aqui 178 00:08:42,300 --> 00:08:44,680 ‫o valor do token. 179 00:08:44,680 --> 00:08:47,750 ‫Assim como esta string aleatória que recebemos antes. 180 00:08:47,750 --> 00:08:51,610 ‫Então, vamos deixá-la como um exemplo, e então 181 00:08:51,610 --> 00:08:53,323 ‫vamos enviar agora. 182 00:08:55,180 --> 00:08:57,913 ‫E então, de fato, devemos obtê-lo aqui. 183 00:08:59,050 --> 00:09:00,310 ‫OK. 184 00:09:00,310 --> 00:09:03,620 ‫Agora o Express transforma automaticamente todos os nomes de cabeçalho 185 00:09:03,620 --> 00:09:06,160 ‫em minúsculas, como você pode ver aqui, 186 00:09:06,160 --> 00:09:09,950 ‫mas é claro, nosso valor de cabeçalho aqui ainda é o mesmo. 187 00:09:09,950 --> 00:09:13,550 ‫Ok, e basicamente esta parte do valor do cabeçalho é 188 00:09:13,550 --> 00:09:15,050 ‫o nosso token. 189 00:09:15,050 --> 00:09:16,870 ‫E é assim que 190 00:09:16,870 --> 00:09:18,720 ‫devemos ler esse token do cabeçalho. 191 00:09:18,720 --> 00:09:19,553 ‫Tudo bem? 192 00:09:20,550 --> 00:09:22,793 ‫Portanto, se realmente 193 00:09:24,130 --> 00:09:29,130 ‫houver necessidade. cabeçalhos. autorização, ok, e 194 00:09:32,730 --> 00:09:34,300 ‫se começar 195 00:09:34,300 --> 00:09:40,643 ‫basicamente com esta string de suporte aqui, ok, então 196 00:09:42,720 --> 00:09:46,670 ‫req. cabeçalhos. autorização e agora 197 00:09:46,670 --> 00:09:48,240 ‫isso é uma string 198 00:09:48,240 --> 00:09:50,050 ‫e então podemos usar startsWith 199 00:09:52,210 --> 00:09:55,290 ‫nisso tudo bem, então isso é apenas JavaScript normal 200 00:09:57,910 --> 00:09:58,930 ‫novamente, ok. 201 00:09:58,930 --> 00:10:03,020 ‫E essas são as condições sob as quais realmente 202 00:10:03,020 --> 00:10:05,430 ‫queremos salvar um token, certo? 203 00:10:05,430 --> 00:10:08,530 ‫Então, novamente, caso o cabeçalho 204 00:10:08,530 --> 00:10:13,260 ‫exista e seu valor comece com Bearer, tudo bem. 205 00:10:13,260 --> 00:10:18,260 ‫Nesse caso, queremos dizer que o token é igual 206 00:10:18,460 --> 00:10:22,257 ‫a req. cabeçalhos. autorização 207 00:10:23,890 --> 00:10:26,810 ‫e agora como obtemos essa segunda 208 00:10:26,810 --> 00:10:28,350 ‫parte da string? 209 00:10:28,350 --> 00:10:30,820 ‫Bem, basicamente vamos dividir a string por 210 00:10:30,820 --> 00:10:33,050 ‫esse caractere de espaço, certo, o 211 00:10:33,050 --> 00:10:34,610 ‫que criará um array 212 00:10:34,610 --> 00:10:35,890 ‫com este 213 00:10:35,890 --> 00:10:37,860 ‫Bearer e com esse token 214 00:10:37,860 --> 00:10:39,690 ‫e então pegaremos aquela parte 215 00:10:39,690 --> 00:10:41,063 ‫do array que queremos. 216 00:10:42,260 --> 00:10:45,080 ‫Então, divida usando espaço e, 217 00:10:45,080 --> 00:10:48,380 ‫a partir desse array, queremos o segundo elemento. 218 00:10:48,380 --> 00:10:49,490 ‫Tudo bem? 219 00:10:49,490 --> 00:10:52,760 ‫Agora, não podemos realmente definir uma variável dentro de 220 00:10:52,760 --> 00:10:53,800 ‫um bloco 221 00:10:53,800 --> 00:10:55,440 ‫if porque const e 222 00:10:55,440 --> 00:10:58,260 ‫let, então a nova variável ES6 declaratória tem 223 00:10:58,260 --> 00:10:59,710 ‫escopo de bloco, e 224 00:10:59,710 --> 00:11:02,650 ‫então tudo o que definirmos neste bloco aqui 225 00:11:02,650 --> 00:11:04,700 ‫não estará disponível fora dele. 226 00:11:05,690 --> 00:11:08,643 ‫Ok, então vamos realmente fazer isso lá fora. 227 00:11:11,970 --> 00:11:16,280 ‫E então simplesmente reatribua esse valor ao token. 228 00:11:16,280 --> 00:11:17,113 ‫OK. 229 00:11:18,670 --> 00:11:21,880 ‫E agora, vamos registrar o token no console apenas 230 00:11:21,880 --> 00:11:23,863 ‫para ver se funciona. 231 00:11:25,130 --> 00:11:28,670 ‫Ok, e na verdade vamos conseguir um token 232 00:11:28,670 --> 00:11:30,373 ‫de verdade aqui. 233 00:11:31,240 --> 00:11:33,253 ‫Aquele com o qual acabamos de fazer login. 234 00:11:35,990 --> 00:11:39,710 ‫E então coloque aquele aqui, certo. 235 00:11:39,710 --> 00:11:40,723 ‫Então 236 00:11:42,360 --> 00:11:45,480 ‫mande e ah! 237 00:11:45,480 --> 00:11:45,480 ‫Aqui vamos nós. 238 00:11:45,480 --> 00:11:49,760 ‫Então, aqui temos nossos dados de token da web JSON que acabamos de enviar 239 00:11:49,760 --> 00:11:51,110 ‫junto com a solicitação. 240 00:11:51,110 --> 00:11:55,120 ‫Vamos desligar rapidamente este log do console aqui. 241 00:11:55,120 --> 00:11:59,590 ‫Certo, e antes de prosseguirmos, vamos verificar 242 00:11:59,590 --> 00:12:03,480 ‫se o token realmente existe. 243 00:12:03,480 --> 00:12:04,313 ‫OK. 244 00:12:05,810 --> 00:12:07,510 ‫Então, se não houver 245 00:12:10,360 --> 00:12:14,090 ‫nenhum token, então, é claro que queremos criar um novo erro. 246 00:12:14,090 --> 00:12:16,630 ‫Certo, e assim como antes 247 00:12:16,630 --> 00:12:19,030 ‫de retornarmos deste middleware e 248 00:12:19,030 --> 00:12:21,260 ‫chamarmos o próximo, ok. 249 00:12:21,260 --> 00:12:24,560 ‫E agora aqui, criaremos um erro e iremos direto 250 00:12:24,560 --> 00:12:26,140 ‫para nosso middleware 251 00:12:26,140 --> 00:12:29,403 ‫de tratamento de erros global com esse erro. 252 00:12:30,487 --> 00:12:33,860 ‫Certo, então, se nenhum token for enviado com a solicitação, 253 00:12:33,860 --> 00:12:35,913 ‫isso significa que não estamos logados. 254 00:12:36,870 --> 00:12:40,310 ‫Então, vamos enviar para o usuário que você não 255 00:12:41,530 --> 00:12:42,373 ‫está logado. 256 00:12:45,610 --> 00:12:48,793 ‫Faça login para obter acesso. 257 00:12:50,137 --> 00:12:52,380 ‫Certo, e agora o código 258 00:12:52,380 --> 00:12:55,090 ‫de status para esse tipo de situação 259 00:12:55,090 --> 00:12:58,040 ‫é 401, o que significa não autorizado, certo? 260 00:12:58,040 --> 00:13:00,430 ‫Não tenho certeza se já usamos esse 261 00:13:00,430 --> 00:13:03,380 ‫antes e sim, na verdade também o fizemos aqui. 262 00:13:03,380 --> 00:13:05,290 ‫Ok, e isso basicamente significa 263 00:13:05,290 --> 00:13:08,890 ‫que os dados que foram enviados na solicitação estão corretos, mas 264 00:13:08,890 --> 00:13:12,110 ‫eles não são suficientes basicamente para obter o acesso do 265 00:13:12,110 --> 00:13:15,050 ‫usuário a um recurso que ele está solicitando. 266 00:13:15,050 --> 00:13:16,080 ‫Tudo bem. 267 00:13:16,080 --> 00:13:17,280 ‫Basta salvá-lo 268 00:13:18,280 --> 00:13:20,270 ‫aqui e testá-lo novamente. 269 00:13:20,270 --> 00:13:24,660 ‫Então, se basicamente tirarmos esse cabeçalho aqui, então 270 00:13:24,660 --> 00:13:28,090 ‫devemos ir direto para aquele erro, 271 00:13:28,090 --> 00:13:29,120 ‫certo? 272 00:13:29,120 --> 00:13:31,910 ‫E, de fato, você não está logado, faça o 273 00:13:31,910 --> 00:13:33,340 ‫login para obter acesso. 274 00:13:33,340 --> 00:13:35,600 ‫Com 401 não autorizado. 275 00:13:35,600 --> 00:13:38,950 ‫Excelente! Então essa parte já está funcionando. 276 00:13:38,950 --> 00:13:41,500 ‫Tudo bem, e agora apenas para recapitular, então 277 00:13:41,500 --> 00:13:44,590 ‫no momento não estamos enviando nenhum token junto com 278 00:13:44,590 --> 00:13:45,903 ‫a solicitação, certo? 279 00:13:47,330 --> 00:13:51,370 ‫E então por esse motivo, claro, não há token, ok? 280 00:13:51,370 --> 00:13:53,380 ‫E, portanto, criamos esse erro, 281 00:13:53,380 --> 00:13:56,680 ‫que acionará nosso middleware de tratamento de erros para enviar 282 00:13:56,680 --> 00:13:59,260 ‫esse erro de volta ao cliente, certo? 283 00:13:59,260 --> 00:14:02,690 ‫E é claro que não temos acesso a 284 00:14:02,690 --> 00:14:05,600 ‫todos os tours, porque esse 285 00:14:05,600 --> 00:14:08,710 ‫middleware é executado antes do controlador getAllTours. 286 00:14:08,710 --> 00:14:13,070 ‫E agora, isso realmente está protegido, certo? 287 00:14:13,070 --> 00:14:17,170 ‫Então, já está funcionando muito bem neste ponto. 288 00:14:17,170 --> 00:14:19,870 ‫Mas é claro que isso está longe de 289 00:14:19,870 --> 00:14:23,480 ‫ser suficiente, porque não é suficiente apenas enviar um token com uma solicitação. 290 00:14:23,480 --> 00:14:26,290 ‫Ele também precisa ser um token válido. 291 00:14:26,290 --> 00:14:28,410 ‫Basicamente, um token em que ninguém 292 00:14:28,410 --> 00:14:30,270 ‫tentou alterar a carga útil. 293 00:14:30,270 --> 00:14:34,110 ‫Ok, e a carga útil, lembre-se, em nosso caso 294 00:14:34,110 --> 00:14:39,110 ‫é sempre o user_id do usuário para o qual o token foi emitido. 295 00:14:39,210 --> 00:14:41,380 ‫Tudo bem, e em 296 00:14:41,380 --> 00:14:44,200 ‫seguida precisamos implementar esta etapa de verificação. 297 00:14:44,200 --> 00:14:47,160 ‫Mas esta palestra já está longa e ainda 298 00:14:47,160 --> 00:14:49,520 ‫há muito o que fazer aqui, 299 00:14:49,520 --> 00:14:52,403 ‫então vamos deixar isso para o próximo vídeo.