1
00:00:02,140 --> 00:00:08,590
Então, como podemos sair dessa tela de autenticação agora se estivermos logados ou se fizemos uma inscrição com sucesso?

2
00:00:09,520 --> 00:00:11,130
Bem, isso não é muito difícil.

3
00:00:11,380 --> 00:00:16,690
Se passarmos por este despacho aqui sem aterrissar no bloco catch, então ele

4
00:00:16,720 --> 00:00:18,730
ainda está aqui no

5
00:00:19,090 --> 00:00:26,560
bloco try, podemos apenas chamar adereços. navegação. navegue exatamente como sempre fizemos e

6
00:00:26,560 --> 00:00:29,470
navegue até a tela diferente que configuramos em

7
00:00:29,470 --> 00:00:37,500
nosso navegador de comutadores, portanto, neste caso, na tela da loja. Então, vamos fazer isso, vamos simplesmente fazer compras e lá por

8
00:00:37,500 --> 00:00:42,950
enquanto, assim que fizermos login com êxito, o que farei agora, isso carrega e

9
00:00:43,030 --> 00:00:45,300
estamos aqui. Agora, recebo um

10
00:00:45,330 --> 00:00:49,300
aviso aqui sobre alguma atualização de estado que não pôde ser executada; esse

11
00:00:49,300 --> 00:00:55,450
conjunto está carregando o estado que agora falha se sairmos. A solução é simplesmente que não devemos tentar atualizar o estado nessa

12
00:00:55,450 --> 00:01:01,000
tela se não estiver mais na tela, para que possamos simplesmente movê-lo para o bloco catch, pois precisamos redefinir o carregamento apenas

13
00:01:01,000 --> 00:01:05,560
se houver um erro porque esse é o único caso em que permanecemos na tela de autenticação; caso

14
00:01:05,560 --> 00:01:07,600
contrário, não precisamos alterar o estado de

15
00:01:07,600 --> 00:01:12,190
carregamento porque estamos deixando a tela de qualquer maneira. Então, com isso, vamos nos

16
00:01:12,190 --> 00:01:13,780
livrar disso também,

17
00:01:13,780 --> 00:01:17,080
se agora tentar novamente, aqui vamos nós e

18
00:01:17,300 --> 00:01:18,170
agora

19
00:01:18,170 --> 00:01:22,730
estamos em nossa loja principal. Agora, é claro, ainda não estamos utilizando

20
00:01:22,730 --> 00:01:24,620
o token, então vamos

21
00:01:24,740 --> 00:01:31,550
fazer isso também. Para isso, vamos ao redutor de autenticação e adicionamos um estado inicial que descreve basicamente com

22
00:01:31,640 --> 00:01:35,850
qual estado queremos iniciar e qual é o nosso general. state shape

23
00:01:36,230 --> 00:01:41,960
is e lá eu quero armazenar o token que inicialmente é nulo e quero armazenar o

24
00:01:41,960 --> 00:01:45,980
userId que inicialmente é nulo, portanto, um estado inicial muito básico.

25
00:01:45,980 --> 00:01:51,230
Em seguida, podemos exportar a função redutora que leva esse estado inicial e também recebe,

26
00:01:52,010 --> 00:01:57,430
é claro, uma ação. Aqui, quero ativar o tipo de ação como sempre e tenho dois

27
00:01:57,430 --> 00:01:59,960
casos nos quais estou interessado agora.

28
00:01:59,980 --> 00:02:08,190
Uma é a ação de logon; portanto, você precisa importar esse identificador da pasta de ações e do arquivo auth

29
00:02:08,190 --> 00:02:12,530
e o outro caso é a ação de inscrição; portanto,

30
00:02:12,580 --> 00:02:14,680
é necessário importar esse

31
00:02:15,820 --> 00:02:25,400
identificador também; em outros casos, eu só quero retorne meu estado. Portanto, se fizermos login, desejo retornar um novo estado onde o

32
00:02:25,400 --> 00:02:33,400
token deve estar, digamos ação. token e userId devem ser ação. userId e essa é a mesma

33
00:02:33,940 --> 00:02:38,530
atualização que eu preciso na inscrição para que possamos copiar isso por lá.

34
00:02:39,220 --> 00:02:44,530
Agora, é claro, precisamos ter certeza de que nossa ação transporta token e userId;

35
00:02:44,530 --> 00:02:51,970
portanto, no criador da ação no final da inscrição aqui, quando despachar a ação de inscrição, precisamos adicionar um

36
00:02:51,970 --> 00:02:55,300
campo de token e adicionar um userId campo.

37
00:02:55,470 --> 00:03:03,670
Agora, o token pode ser obtido a partir dos dados de resposta, existe esse token de ID e o mesmo aqui, resData não é um token de ID,

38
00:03:03,670 --> 00:03:09,250
mas é localId e você vê isso aqui no log, localId, esse aqui é o userId e, se você

39
00:03:09,280 --> 00:03:16,530
rolar para cima , Token de identificação, esse é o token. Então é isso que eu envio aqui e podemos

40
00:03:17,070 --> 00:03:21,140
copiar isso e usar o mesmo, quase o mesmo para fazer

41
00:03:21,150 --> 00:03:28,140
login, a única coisa que precisa mudar é esse identificador e você pode até unir o login e inscrever-se

42
00:03:28,140 --> 00:03:34,800
em um identificador de autenticação combinado, digamos porque em um redutor, estamos fazendo a mesma coisa de qualquer maneira.

43
00:03:34,920 --> 00:03:40,200
Então, eu apenas o dividi aqui para ficar claro que temos duas coisas diferentes no final, mas a

44
00:03:40,200 --> 00:03:44,420
atualização é a mesma, então podemos definitivamente combinar esses dois tipos de ação.

45
00:03:45,250 --> 00:03:48,970
Então, com isso, agora estamos armazenando o token e isso é legal,

46
00:03:49,330 --> 00:03:51,990
mas para que precisamos desse token novamente?

47
00:03:52,150 --> 00:03:59,700
Precisamos do token que agora estamos armazenando para acessar nossa API e, para isso, vamos ao Firebase e ao banco

48
00:03:59,700 --> 00:04:00,870
de dados.

49
00:04:00,870 --> 00:04:05,940
Lembre-se de que, quando configuramos esse banco de dados, mencionei que você deveria iniciar

50
00:04:05,940 --> 00:04:11,370
neste modo de teste, se lembrar. O que isso fez foi configurar determinadas regras e você

51
00:04:11,370 --> 00:04:15,810
pode verificá-las se clicar na guia Regras. Isso controla quem pode ler e gravar em seu

52
00:04:15,810 --> 00:04:20,730
banco de dados e, no momento, isso é definido como verdadeiro, o que significa que todos podem ler tudo e

53
00:04:20,820 --> 00:04:21,930
todos podem escrever tudo.

54
00:04:22,230 --> 00:04:32,630
Obviamente, isso não é o que você deseja; em vez disso, definirei os dois para autenticação desigual como nulo, o que pode parecer estranho e isso deve ser aspas

55
00:04:32,630 --> 00:04:39,200
duplas, mas essa é a sintaxe do Firebase e você pode aprender mais sobre as regras aqui. clicando

56
00:04:39,200 --> 00:04:44,480
em saiba mais ou simplesmente no Google for Firebase, as regras de segurança do

57
00:04:44,480 --> 00:04:46,960
banco de dados em tempo real.

58
00:04:47,000 --> 00:04:53,000
O que isso diz ao Firebase é que apenas usuários autenticados, portanto, somente usuários que enviam

59
00:04:53,000 --> 00:04:57,400
a solicitação com um token válido devem poder ler e escrever.

60
00:04:57,560 --> 00:05:00,080
Agora você pode até argumentar que o Redux sempre

61
00:05:00,110 --> 00:05:06,710
deve ser permitido, podemos definir isso como verdadeiro e você pode ser ainda mais específico em relação às regras, para dizer que o Redux

62
00:05:06,710 --> 00:05:07,970
de produtos é permitido,

63
00:05:07,970 --> 00:05:09,770
o Redux de pedidos não é,

64
00:05:09,800 --> 00:05:13,200
mas novamente isso é algo que você pode verificar com os documentos oficiais.

65
00:05:13,370 --> 00:05:18,950
Eu irei com a configuração em que o Redux sempre é permitido, mas a escrita não é.

66
00:05:19,010 --> 00:05:22,160
Portanto, agora, para escrever, precisamos de

67
00:05:22,160 --> 00:05:28,640
um token, caso contrário, enfrentaremos um problema. Se fizermos login aqui e estivermos armazenando o token, mas não

68
00:05:28,640 --> 00:05:30,440
o anexarmos às solicitações no

69
00:05:30,650 --> 00:05:33,060
momento, você verá que podemos carregar todos

70
00:05:33,320 --> 00:05:38,510
os dados, tudo bem, mas você também notará que, se eu tentar editar isso e remover alguns

71
00:05:38,510 --> 00:05:45,420
dos pontos de exclamação aqui, no final, recebo um erro e esse erro é gerado porque não tenho permissão para escrever e,

72
00:05:45,420 --> 00:05:49,190
portanto, o Firebase bloqueia o acesso e retorna uma resposta de erro.

73
00:05:49,190 --> 00:05:54,890
Portanto, agora precisamos aproveitar o token armazenado em um redutor e, na verdade, anexá-lo às nossas

74
00:05:54,890 --> 00:05:56,360
solicitações de saída.

75
00:05:56,360 --> 00:06:00,940
Agora, antes de tudo, precisamos registrar esse redutor em

76
00:06:00,950 --> 00:06:08,300
nosso redutor de raiz, portanto, no aplicativo. arquivo js, precisamos importá-lo, precisamos importar o redutor de autenticação da loja e

77
00:06:08,300 --> 00:06:14,780
lá a pasta redutores e, o arquivo auth e adicioná-lo aos redutores combinados, talvez esteja aqui com a chave auth, mas é claro

78
00:06:14,780 --> 00:06:20,030
que você pode usar qualquer chave que você quiser. Isso nos permitirá alavancar isso

79
00:06:20,240 --> 00:06:26,360
e acessar esse token, mas agora precisamos anexá-lo às solicitações de saída, por exemplo, para

80
00:06:26,360 --> 00:06:29,450
produtos, precisamos anexá-lo à solicitação que enviamos

81
00:06:29,510 --> 00:06:38,090
para atualizar produtos, de modo que seria essa solicitação aqui. Agora, a maneira como você anexa uma solicitação no Firebase pode ser

82
00:06:38,090 --> 00:06:44,570
encontrada nos documentos oficiais do Firebase para autenticação do usuário do banco de dados em tempo real aqui. No

83
00:06:44,570 --> 00:06:52,640
final, o que você aprendeu é que você pode anexar um token à sua solicitação de saída simplesmente adicionando essa consulta de autenticação parâmetro

84
00:06:52,760 --> 00:06:55,540
no final do seu URL de solicitação.

85
00:06:55,790 --> 00:06:59,690
Então aqui no final, precisamos adicionar um ponto de interrogação igual

86
00:07:00,080 --> 00:07:06,160
e, então, aqui, precisamos ter nosso token. Agora, como podemos obter acesso ao token aqui?

87
00:07:06,180 --> 00:07:12,790
Estamos no criador da ação, o que significa que não temos acesso fácil à

88
00:07:13,070 --> 00:07:20,390
loja aqui, à loja Redux ou não? Redux Thunk, aquele pacote legal que nos permite escrever essa sintaxe com

89
00:07:20,390 --> 00:07:24,720
a função que recebe a função de despacho, que na verdade nos dá algo doce.

90
00:07:24,800 --> 00:07:30,860
Também podemos alterar um pouco essa função e não apenas obter despacho, mas também obter um segundo

91
00:07:30,860 --> 00:07:35,250
argumento, que é outra função que nos dá acesso ao estado Redux, para

92
00:07:35,510 --> 00:07:43,230
que tenhamos acesso ao estado atual de nossa loja Redux. Portanto, se eu registrar o resultado do estado get aqui, vamos

93
00:07:43,230 --> 00:07:45,300
ver o que isso nos

94
00:07:45,300 --> 00:07:51,860
dá e, para evitar erros, por enquanto, aqui apenas adicionarei uma string vazia para que possamos testar esse código.

95
00:07:51,870 --> 00:07:56,400
Obviamente, isso não vai funcionar, mas vamos corrigi-lo em breve, então vamos ver o que está dentro desse estado se executarmos

96
00:07:56,400 --> 00:07:56,700
isso.

97
00:08:00,000 --> 00:08:00,540
Então,

98
00:08:00,570 --> 00:08:03,660
é hora de fazer login novamente muito rápido e,

99
00:08:04,550 --> 00:08:09,010
em seguida, vá para a tela do administrador e tente editar isso, o que

100
00:08:09,970 --> 00:08:13,300
obviamente ainda falhará, mas isso não importa, porque agora, se eu

101
00:08:13,420 --> 00:08:19,690
clicar aqui, sim, falhará, mas o que você verá aqui no log, o que obtemos é uma saída completa de

102
00:08:19,780 --> 00:08:22,270
nossa loja Redux completa. Esta é a nossa

103
00:08:22,270 --> 00:08:28,570
loja Redux, obtemos um objeto com nossa fatia de estado de autenticação que ainda tem outro objeto com nosso token e com

104
00:08:28,570 --> 00:08:34,880
o ID do usuário, nossa fatia de estado do cartão, nossa fatia de estado de pedidos e nossa fatia de estado de produtos.

105
00:08:34,960 --> 00:08:40,540
Portanto, isso permite que eu tenha acesso ao meu repositório Redux e ao token, para que

106
00:08:40,540 --> 00:08:48,060
o token possa ser buscado executando getState. auth. token, porque isso nos dá acesso

107
00:08:48,070 --> 00:08:53,890
ao nosso repositório completo do Redux, e então nos dá acesso à fatia de autenticação e à propriedade

108
00:08:53,890 --> 00:08:59,810
do token que estamos gerenciando nessa fatia de autenticação. E agora no criador de

109
00:09:00,090 --> 00:09:09,440
ações de produtos, podemos adicionar esse token aqui no final. Portanto, aqui podemos apenas substituir essa string pela variável token que

110
00:09:09,440 --> 00:09:11,600
contém nosso token e

111
00:09:11,600 --> 00:09:17,330
agora, se salvarmos isso, com esta pequena alteração, se agora fizermos login novamente e

112
00:09:17,390 --> 00:09:20,000
mais tarde também mudaremos isso, de

113
00:09:20,000 --> 00:09:27,490
modo que não precisaremos constantemente relogin, não se preocupe. Se fizermos login novamente, vamos ao admin, clique em adicioná-lo aqui e agora

114
00:09:27,710 --> 00:09:33,800
tentamos isso, isso funciona novamente porque agora o token está anexado, o Firebase o valida e determina que é válido porque

115
00:09:33,830 --> 00:09:35,890
é claro que não nos misturamos

116
00:09:35,900 --> 00:09:39,170
com ele , é um token válido e, portanto, isso simplesmente funciona.

117
00:09:39,200 --> 00:09:43,190
Agora, não precisamos apenas do token quando atualizamos nossos produtos, também

118
00:09:43,190 --> 00:09:48,410
precisamos quando adicionamos um novo produto. Então, copio essa lógica e adiciono a

119
00:09:48,410 --> 00:09:54,310
mesma aqui. Quando criamos um produto, recebo meu token com a ajuda desse segundo argumento, que

120
00:09:54,310 --> 00:09:56,330
podemos obter aqui se precisarmos,

121
00:09:56,440 --> 00:10:03,320
a função get state e isso me permite altere essas aspas simples para back ticks, para que eu possa adicionar

122
00:10:03,320 --> 00:10:09,530
convenientemente esse parâmetro de consulta aqui no final com ponto de interrogação igual e igual ao meu token.

123
00:10:09,530 --> 00:10:15,300
Portanto, agora podemos criar um produto e atualizar um produto, excluir, claro, também é

124
00:10:15,410 --> 00:10:22,430
uma solicitação de gravação. Portanto, para excluir o produto, farei o mesmo, obter acesso à minha loja com

125
00:10:22,430 --> 00:10:29,130
a função get state aqui e adicionar ponto de interrogação daqui no final e adicione o token.

126
00:10:29,300 --> 00:10:30,290
Então isso é uma coisa.

127
00:10:30,320 --> 00:10:36,260
Agora, nos pedidos, é uma coisa semelhante, lá para buscar, não precisamos disso, mas para adicionar, precisamos porque adicionar

128
00:10:36,290 --> 00:10:38,260
é uma operação de gravação.

129
00:10:38,480 --> 00:10:45,110
Então, lá, obtemos o estado, se quisermos, podemos extrair o token de lá com a mesma abordagem de antes

130
00:10:45,110 --> 00:10:52,880
e podemos anexá-lo aqui e ali; na verdade, também precisaremos do userId em breve, portanto, tomaremos cuidado sobre isso na próxima aula,

131
00:10:52,880 --> 00:10:54,860
mas, por enquanto, apenas anexe

132
00:10:54,860 --> 00:10:57,810
o token em todos os lugares e agora

133
00:10:57,890 --> 00:11:02,570
vamos ver como podemos garantir que os pedidos realmente pertençam ao nosso usuário.