WEBVTT

00:00:07.857 --> 00:00:10.402
No desenvolvimento 
de uma aplicação web,

00:00:10.402 --> 00:00:14.900
uma das principais coisas
que vamos ter é o http,

00:00:14.900 --> 00:00:19.137
ele é basicamente a base de tudo
o que nós fazemos.

00:00:19.137 --> 00:00:23.648
E veja, não estamos falando aqui
só de aplicação para o navegador,

00:00:23.648 --> 00:00:27.574
o HTTP também está embarcado
em aplicações mobile

00:00:27.574 --> 00:00:32.564
e mesmo alguns sistemas que nós 
pensamos que foram desenvolvidos

00:00:32.564 --> 00:00:34.486
com a estrutura compilada.

00:00:34.486 --> 00:00:36.976
Isso porque ele trabalha 
muito bem

00:00:36.976 --> 00:00:40.845
com essa ideia de interação 
cliente servidor.

00:00:40.845 --> 00:00:44.002
Muito disso se deve 
aos seus métodos.

00:00:44.002 --> 00:00:46.123
E aí podemos destacar os principais,

00:00:46.123 --> 00:00:50.071
que são: o GET
que eu obtenho informação,

00:00:50.071 --> 00:00:54.219
o POST que eu publico 
uma informação,

00:00:54.219 --> 00:00:59.781
PUT, eu adiciono uma informação 
para alguém que já existe.

00:00:59.781 --> 00:01:04.281
No caso, por exemplo, um usuário
ou um campo que já está determinado

00:01:04.281 --> 00:01:07.288
e DELETE onde eu mando 
remover alguém.

00:01:07.288 --> 00:01:09.474
Foi justamente essa estrutura

00:01:09.474 --> 00:01:13.058
que moldou todo o mercado de TI
que conhecemos hoje em dia,

00:01:13.058 --> 00:01:15.679
principalmente 
nas aplicações web.

00:01:15.679 --> 00:01:17.452
É através deles que conseguimos

00:01:17.452 --> 00:01:20.393
enviar, receber ou alterar 
algum dado

00:01:20.393 --> 00:01:22.985
nos sistemas que usamos 
no dia a dia.

00:01:22.985 --> 00:01:25.645
Mas esses caras 
não estão sozinhos,

00:01:25.645 --> 00:01:27.840
em especial porque o HTTP

00:01:27.840 --> 00:01:30.344
normalmente tem um problema 
de segurança.

00:01:30.344 --> 00:01:33.428
Esses dados estão expostos 
na rede

00:01:33.428 --> 00:01:36.979
disponível para qualquer hacker 
poder acessar.

00:01:36.979 --> 00:01:40.665
Justamente por isso 
que veio o https,

00:01:40.665 --> 00:01:44.611
onde temos a parte de segurança
sendo implementada.

00:01:44.611 --> 00:01:46.002
E é nele, por exemplo,

00:01:46.002 --> 00:01:48.322
que ganhamos a criptografia

00:01:48.322 --> 00:01:50.865
dos dados 
que estamos operando.

00:01:50.865 --> 00:01:56.067
E aqui também vamos ter que ter
alguns detalhes a se atentar

00:01:56.067 --> 00:02:00.589
toda URL que esse endereço 
de acesso às páginas web

00:02:00.589 --> 00:02:04.108
será composta 
por protocolo

00:02:04.108 --> 00:02:07.787
no caso HTTP, 
o HTTPS,

00:02:07.787 --> 00:02:10.568
o DNS que 
estamos acessando,

00:02:10.568 --> 00:02:15.593
que é o nome do domínio da página
ou da aplicação que eu quero acessar,

00:02:15.593 --> 00:02:19.985
e uma porta, que é um número 
que vai lá no final.

00:02:19.985 --> 00:02:22.968
E se você nunca viu 
esse número antes,

00:02:22.968 --> 00:02:26.130
é porque ele é subentendido 
em alguns casos.

00:02:26.130 --> 00:02:30.004
Por exemplo, 
o HTTP utiliza a porta 80,

00:02:30.004 --> 00:02:34.364
o HTTPS utiliza
a porta 443.

00:02:34.364 --> 00:02:36.184
Mas caso desenvolva, 
por exemplo,

00:02:36.184 --> 00:02:39.202
um front end ou um
dashboard de API,

00:02:39.202 --> 00:02:42.567
é normal colocarmos esse cara
lá na porta 5000,

00:02:42.567 --> 00:02:45.071
e aí eu preciso especificar 
esse endereço.

00:02:45.071 --> 00:02:48.440
Se nós acessamos, por exemplo,
o site do Google,

00:02:48.440 --> 00:02:51.143
já podemos ver
como é que esse cara vai funcionar.

00:02:51.143 --> 00:02:56.426
Notem que já temos aqui
o nosso protocolo HTTPS,

00:02:56.426 --> 00:02:59.821
indicando que é só 
uma conexão segura.

00:02:59.821 --> 00:03:02.722
Mas veja, não é porque 
eu tenho um https aqui

00:03:02.722 --> 00:03:05.138
que eu estou 100% seguro.

00:03:05.138 --> 00:03:10.813
Na realidade isso só diz
que eu tenho um certificado em uso,

00:03:10.813 --> 00:03:14.518
não necessariamente
que esse é o certificado do Google,

00:03:14.518 --> 00:03:17.155
já já nós vamos ver como 
é que validamos isso.

00:03:17.155 --> 00:03:22.090
Na sequência
nós temos o endereço DNS do Google

00:03:22.090 --> 00:03:27.188
e aqui está subtendido
a porta 443.

00:03:27.188 --> 00:03:30.751
"Professor, como é que conseguimos
vertodos esses detalhes?"

00:03:30.751 --> 00:03:33.524
se clicarmos aqui
em cima do ícone do Google

00:03:33.524 --> 00:03:36.854
ou clicar em cima 
do cadeado que aparece

00:03:36.854 --> 00:03:39.731
quando temos 
aqui o HTTPS,

00:03:39.731 --> 00:03:44.143
nós conseguimos ver 
as informações desse site.

00:03:44.143 --> 00:03:47.605
Por exemplo, ele está indicando
que essa conexão a segura,

00:03:47.605 --> 00:03:50.192
se eu clico para pedir 
mais informações,

00:03:50.192 --> 00:03:54.582
ele me traz um briefing
e me traz um acesso ao certificado.

00:03:54.582 --> 00:03:57.244
Onde eu consigo checar, 
por exemplo,

00:03:57.244 --> 00:04:00.373
quem foi que emitiu 
esse certificado.

00:04:00.373 --> 00:04:02.731
No caso, esse certificado
foi emitido para o Google

00:04:02.731 --> 00:04:06.581
por uma companhia 
chamada "GTS CA 1C3"

00:04:06.581 --> 00:04:10.609
que no caso é o próprio
serviço de segurança da Google.

00:04:10.609 --> 00:04:14.120
Também conseguimos ver
a data de emissão

00:04:14.186 --> 00:04:17.089
e os efeitos de uso 
desse certificado,

00:04:17.089 --> 00:04:19.925
como por exemplo 
a chave pública.

00:04:19.925 --> 00:04:23.329
Isso porque toda comunicação https

00:04:23.329 --> 00:04:26.565
funciona baseada 
em chave pública e privada.

00:04:26.632 --> 00:04:29.635
A chave pública 
nós vamos utilizar

00:04:29.635 --> 00:04:33.839
para assinar qualquer dado 
e mandar para o servidor,

00:04:33.939 --> 00:04:34.573
afinal, só a chave privada 
vai abrir esse dado.

00:04:37.877 --> 00:04:42.314
Já quando eu assino com a chave privada,
a pública consegue abrir,

00:04:42.381 --> 00:04:47.119
e isso não é tão interessante
quando eu quero garantir segurança.

00:04:47.219 --> 00:04:49.121
E aí, como é que eu faço?

00:04:49.121 --> 00:04:53.359
Normalmente, quando eu chamo esse site,
a gente já negocia ali,

00:04:53.359 --> 00:04:58.464
utilizando as chaves públicas,
um acordo de senha para a gente

00:04:58.464 --> 00:05:02.268
usar um outro certificado privado
para a gente usar.

00:05:02.334 --> 00:05:05.104
E dessa forma a gente escapa
desse problema

00:05:05.104 --> 00:05:09.642
do assinar com a chave privada
e ler com a chave pública.

00:05:09.708 --> 00:05:13.512
Outro detalhe importante
é que a gente tem mais algumas informações

00:05:13.512 --> 00:05:16.949
e detalhes sobre esse certificado.

00:05:17.049 --> 00:05:20.352
Mas voltando aqui no quadradinho,
vejam que a gente também

00:05:20.352 --> 00:05:26.659
vai ter algumas opções,
como os cookies que estão em uso ou mesmo

00:05:26.759 --> 00:05:28.093
as informações sobre os

00:05:28.093 --> 00:05:32.231
trekkings, que são os acessos
que a gente está pedindo.

00:05:32.297 --> 00:05:34.900
Os trekkings vão ser referentes
a basicamente

00:05:34.900 --> 00:05:38.737
qualquer coisa que a gente queira acessar,
desde a localização

00:05:38.804 --> 00:05:43.342
ou até a possibilidade de armazenar
algum dado no computador.

00:05:43.442 --> 00:05:47.679
Só que o CUC ele
é um pouquinho mais delicado, o cookie.

00:05:47.679 --> 00:05:50.949
Teoricamente
são dados que nós estamos salvando

00:05:50.949 --> 00:05:54.253
nessa máquina
para acelerar a nossa página.

00:05:54.319 --> 00:05:56.855
Ela é uma espécie de client side

00:05:56.855 --> 00:05:59.591
ou processamento do lado cliente,

00:05:59.591 --> 00:06:03.529
aonde a gente
consegue aliviar o tráfego do servidor,

00:06:03.629 --> 00:06:06.965
só que expondo ao risco de ter parte

00:06:06.965 --> 00:06:10.302
do meu código disponível
na máquina do usuário.

00:06:10.369 --> 00:06:14.640
Além disso, Cookie também salva
vários outros componentes da página,

00:06:14.740 --> 00:06:18.677
como fotos muito acessadas,
logomarcas e coisas do gênero.

00:06:18.744 --> 00:06:21.380
Então ele está em Minas sendo usado.

00:06:21.380 --> 00:06:24.917
O problema é qual dado eu to passando
pra ele já.

00:06:24.917 --> 00:06:28.887
Quando a gente fala do server side,
ele vai compor

00:06:28.987 --> 00:06:32.524
todos os dados
que a gente tem do lado do servidor

00:06:32.591 --> 00:06:35.527
e aí a gente termina
tendo um pouco mais de segurança.

00:06:35.527 --> 00:06:38.997
Eu vou me preocupar muito com o ataque
que vou tentar explorar,

00:06:39.097 --> 00:06:42.067
mas isso tudo vai vir via rede

00:06:42.100 --> 00:06:47.639
e não simplesmente disponibilizei esse
código aberto para todo mundo.

00:06:47.739 --> 00:06:48.740
Além disso,

00:06:48.740 --> 00:06:52.578
essa nossa
interação nem sempre é bem sucedida

00:06:52.644 --> 00:06:56.181
e justamente por isso o HTTP tem códigos.

00:06:56.281 --> 00:06:59.284
Toda vez que você recebe um código
200, por exemplo,

00:06:59.351 --> 00:07:02.554
é porque a sua solicitação deu certo.

00:07:02.621 --> 00:07:06.692
Toda a família 200
quer dizer, solicitação bem sucedida.

00:07:06.758 --> 00:07:10.062
Já quando a gente fala da família 500,
a gente está falando

00:07:10.062 --> 00:07:12.030
da família, dos erros.

00:07:12.030 --> 00:07:15.667
O famoso erro 404 já está noutra família

00:07:15.667 --> 00:07:20.639
para indicar falha no server side,
aonde eu não consegui achar o endereço.

00:07:20.739 --> 00:07:25.477
Então cada código
vai ter ali a sua família

00:07:25.544 --> 00:07:30.482
e dentro dessas famílias
os erros que ele está justificando.

00:07:30.549 --> 00:07:33.552
Veja que só para manter uma aplicação
web no ar

00:07:33.585 --> 00:07:34.386
a gente já tem que ter

00:07:34.386 --> 00:07:38.724
uma série de cuidados
e trabalhar minunciosamente vários pontos.

00:07:38.824 --> 00:07:41.460
Mas são justamente esses pequenos pontos

00:07:41.460 --> 00:07:44.763
que me permitem arquitetar uma solução web

00:07:44.830 --> 00:07:48.567
que vai ser ao
mesmo tempo útil e segura. E.