vimeo.com/.../929617616

No desenvolvimento
de uma aplicação web,

uma das principais coisas
que vamos ter é o http,

ele é basicamente a base de tudo
o que nós fazemos.

E veja, não estamos falando aqui
só de aplicação para o navegador,

o HTTP também está embarcado
em aplicações mobile

e mesmo alguns sistemas que nós
pensamos que foram desenvolvidos

com a estrutura compilada.

Isso porque ele trabalha
muito bem

com essa ideia de interação
cliente servidor.

Muito disso se deve
aos seus métodos.

E aí podemos destacar os principais,

que são: o GET
que eu obtenho informação,

o POST que eu publico
uma informação,

PUT, eu adiciono uma informação
para alguém que já existe.

No caso, por exemplo, um usuário
ou um campo que já está determinado

e DELETE onde eu mando
remover alguém.

Foi justamente essa estrutura

que moldou todo o mercado de TI
que conhecemos hoje em dia,

principalmente
nas aplicações web.

É através deles que conseguimos

enviar, receber ou alterar
algum dado nos sistemas

que usamos
no dia a dia.

Mas esses caras
não estão sozinhos,

em especial porque o HTTP

normalmente tem um problema
de segurança.

Esses dados estão expostos
na rede disponível

para qualquer hacker
poder acessar.

Justamente por isso
que veio o https,

onde temos a parte de segurança
sendo implementada.

E é nele, por exemplo,

que vemos a criptografia dos dados
que estamos operando.

E aqui também vamos ter que ter
alguns detalhes a apresentar,

toda URL que esse endereço
de acesso às páginas web

vai ser composta
por protocolo

no caso HTTP,
o HTTPS,

o DNS que
estamos acessando,

que é o nome do domínio da página
ou da aplicação que eu quero acessar

é uma porta que é um número
que vai lá no final.

E se você nunca viu
esse número antes,

é porque ele é subentendido
em alguns casos.

Por exemplo,
o HTTP utiliza a porta 80,

o HTTPS utiliza
a porta 443.

Mas caso desenvolva,
por exemplo,

um front end ou um
dashboard de API,

é normal a gente colocar esse cara
lá na porta 5000.

E aí eu preciso especificar
esse endereço,

se nós acessamos, por exemplo,
o site do Google,

já podemos ver
como é que esse cara vai funcionar.

Notem que já temos aqui
o nosso protocolo HTTPS,

indicando que é só
uma conexão segura.

Mas veja, não é porque
eu tenho um https aqui

que eu estou 100% seguro.

Na realidade isso só diz
que eu tenho um certificado em uso,

não necessariamente
que esse é o certificado do Google.

Já já a gente
vê como é que a gente valida isso.

Na sequência
nós temos o endereço DNS do Google

e aqui está subtendido
a porta quatro, quatro, três.

Como é

que a gente consegue ver
todos esses detalhes?

Se a gente clicar aqui
em cima do ícone do Google

ou clica em cima do dia
a dia em que aparece?

Quando a gente tem aqui o HTTPS,

nós conseguimos ver as informações desse
site.

Por exemplo, ele está indicando
que essa conexão a segura.

Se eu clico para pedir mais informações,

ele me traz um briefing
e me traz um acesso ao certificado,

aonde eu consigo checar, por exemplo,

quem foi que emitiu esse certificado.

No caso, esse cara foi emitido pra Google
por uma companhia chamada GTS.

Será um C3, que no caso é o próprio
serviço de segurança da Google.

A gente também consegue ver
a data de emissão

e os efeitos de uso desse certificado,

como por exemplo a chave pública.

Isso porque toda comunicação https
funciona

baseada em chave pública e privada.

A chave pública a gente vai utilizar

para assinar qualquer
dado qualquer e mandar para o servidor,

afinal,

só a chave privada vai abrir esse dado.

Já quando eu assino com a chave privada,
a pública consegue abrir.

E isso não é tão interessante
quando eu quero garantir segurança.

E aí, como é que eu faço?

Normalmente, quando eu chamo esse site,
a gente já negocia ali,

utilizando as chaves públicas,
um acordo de senha para a gente

usar um outro certificado privado
para a gente usar.

E dessa forma a gente escapa
desse problema

do assinar com a chave privada
e ler com a chave pública.

Outro detalhe importante
é que a gente tem mais algumas informações

e detalhes sobre esse certificado.

Mas voltando aqui no quadradinho,
vejam que a gente também

vai ter algumas opções,
como os cookies que estão em uso ou mesmo

as informações sobre os

trekkings, que são os acessos
que a gente está pedindo.

Os trekkings vão ser referentes
a basicamente

qualquer coisa que a gente queira acessar,
desde a localização

ou até a possibilidade de armazenar
algum dado no computador.

Só que o CUC ele
é um pouquinho mais delicado, o cookie.

Teoricamente
são dados que nós estamos salvando

nessa máquina
para acelerar a nossa página.

Ela é uma espécie de client side

ou processamento do lado cliente,

aonde a gente
consegue aliviar o tráfego do servidor,

só que expondo ao risco de ter parte

do meu código disponível
na máquina do usuário.

Além disso, Cookie também salva
vários outros componentes da página,

como fotos muito acessadas,
logomarcas e coisas do gênero.

Então ele está em Minas sendo usado.

O problema é qual dado eu to passando
pra ele já.

Quando a gente fala do server side,
ele vai compor

todos os dados
que a gente tem do lado do servidor

e aí a gente termina
tendo um pouco mais de segurança.

Eu vou me preocupar muito com o ataque
que vou tentar explorar,

mas isso tudo vai vir via rede

e não simplesmente disponibilizei esse
código aberto para todo mundo.

Além disso,

essa nossa
interação nem sempre é bem sucedida

e justamente por isso o HTTP tem códigos.

Toda vez que você recebe um código
200, por exemplo,

é porque a sua solicitação deu certo.

Toda a família 200
quer dizer, solicitação bem sucedida.

Já quando a gente fala da família 500,
a gente está falando

da família, dos erros.

O famoso erro 404 já está noutra família

para indicar falha no server side,
aonde eu não consegui achar o endereço.

Então cada código
vai ter ali a sua família

e dentro dessas famílias
os erros que ele está justificando.

Veja que só para manter uma aplicação
web no ar

a gente já tem que ter

uma série de cuidados
e trabalhar minunciosamente vários pontos.

Mas são justamente esses pequenos pontos

que me permitem arquitetar uma solução web

que vai ser ao
mesmo tempo útil e segura. E.