estou com dificuldades em assinar na platafoma da rocketseat, eu vivo em Angola e não tenho um cpf Brasileiro e o sistema não me permitir continuar com a assinatura sem inserir um cpf e um cep
@chrisdevindev26 күн бұрын
conseguiu mano?
@gabrielmesquita87046 ай бұрын
Perfeito!! Gostaria muito de um vídeo fazendo autenticação com nextjs 14 e nodejs no backend, lidando com toda a parte de autenticação com jwt. Tem vídeos no youtube ensinando, mas não é com a mesma qualidade da rocket.
@matheuspassos86506 ай бұрын
up!
@Mario-PWZ6 ай бұрын
UP 2 !
@RafaelGomes016 ай бұрын
UP 3 😅
@DiogoMoreira06106 ай бұрын
up 4
@lucasdeandradeoficial6 ай бұрын
...com a parte do Refresh Token também esta faltando
@LuanHenrique-pc3nn6 ай бұрын
Eu amo a capacidade que a Rocket tem de lançar um vídeo 1 dia antes de acontecer o meu problema KKKKK Fiquei com duvida nisso AGORA e o primeiro video q me aparece no KZbin é a solução do meu problema kkkkk
@vini15206 ай бұрын
Você pode usar token jwt , e quando precisar salvar algo, usar alguma estratégia de cache (como redis). E nas telas mais sensíveis , pedir uma segunda senha
@trechosdelivros4445Ай бұрын
Eu estou criando um token quando o usuário se cadastra, esse token é armazenado no banco de dados, e quando ele se autentica os dados são gerados. Tem algum problema nesta abordagem ?
@filipesantos800125 күн бұрын
@@trechosdelivros4445 Mano acho que na prática o maior problema vai ser o consumo do banco sem muita necessidade (já que isso meio que significaria pagar mais quando tivesse no ar e estivesse crescendo), o JWT funciona de uma forma que você nunca vai precisar armazenar ele, já que ele só precisa ser valido para funcionar e quando não for mais (expirou) o backend já vai conseguir invalidar aquela requisição, a única coisa que vejo sentido em armazenar é o refresh token caso você queira utilizar no seu projeto.
@trechosdelivros444525 күн бұрын
@@filipesantos8001 Eu usei o JWT para autenticação e o session storage para armazenar o ID para fazer o push de dados após a autenticação… você vê algum problema nessa abordagem?
@CarlosEduardo42Ай бұрын
Possuo uma aplicação do next que salva o jwt nos cookies com http only. Se eu precisar, pelo front-end, fazer uma requisição diretamente para a API do servidor, ela faz a requisição para a url /api/caminho-da-api. Ainda no Next, tenho um arquivo em /app/api/[..all]/route.ts. Este arquivo de rota pega tudo o que vier depois da /api/ e envia para a URL da API externa, junto com o jwt que só o back tem acesso, com todo o conteúdo da requisição.
@PedroHenrique-je6yu6 ай бұрын
up pra fazerem um vídeo com autenticação jwt + nextjs14
@DevEmpreender-l2w6 ай бұрын
Essas lives acontecem aonde?
@edu_amr6 ай бұрын
Deveria ter um video fzd uma tela auth com React puro junto com auth de rotas publicas e privadas
@ryanpantaneiro6 ай бұрын
no meu projeto, em qualquer requisição que envio pro back-end, preciso enviar o token no cabeçalho, até aí tudo bem, a dúvida é, o projeto tem diversas roles diferentes (perfil de acesso) e cada role muda muito as permissões ou páginas que aparecem. O back-end me envia pelo cabeçalho a role do usuário logado, mas eu sinceramente estou com dúvidas de qual a melhor forma de sempre verificar e mostrar as telas que são permitidas dependendo da role. No React a melhor maneira seria usando contexto global?
@u9s0e9r6 ай бұрын
Vc pode proteger as paginas que vc quiser com conditional rendering.
@GustavoAlves-pf7lf6 ай бұрын
Guarda dentro do JWT a role, ou permissões, caso queira mais escalabilidade. No frontend, faz um decode do JWT e controla a renderização da tela baseada na role ou na permissão, crie um contexto global e no seu router, consuma isso e renderize as rotas condicionalmente, dá para escalar isso muito bem. No backend, crie um middleware que também faça esse decode e guarde no contexto do usuário a role ou as permissões. Com essa informação, você consegue restringir endpoints e mudar comportamentos como resposta, etc.
@ryanpantaneiro5 ай бұрын
obrigado, meus manos!!
@gilOliveira0016 ай бұрын
No começo eu não tava entendendo..no final parecia que eu tava no começo kkkk obs: sou iniciante
@bonk14636 ай бұрын
Adoraria que tivesse um lib que cuidasse disso tudo automático pra NestJS e frontend. Tivemos que implementar isso na mão com Keycloak e foi várias horas arrumando bugs e a implementação em sí.
@maykonsousa846 ай бұрын
Eu uso o next-auth ou clerk que já gerencia isso tudo via cookies, inclusive com login social
@bonk14636 ай бұрын
@@maykonsousa84 não podia usar o Clerk, regra do projeto, next-auth deu mais problema do que ajudou pq ele é pro next e não integrou tão bem com nestjs.
@erickcabral510718 күн бұрын
Onde ele faz live?
@carlosallbertodev6 ай бұрын
Diegão estou com uma dúvida no next 14 men. Qual a melhor maneira para fazer uma requisição com fetch pasando o jwt que está nos cookies pegar os valores e renderizar no lado do client?
@trechosdelivros4445Ай бұрын
Tô com essa dúvida também, para quebrar o galho, eu armazeno o id do token criado no registro diretamente em um campo do banco de dados e para fazer a renderização eu puxo por esse campo.
@christianrodriguesdesouza55625 ай бұрын
Explicação muito boa man 👏🏻👏🏻👏🏻
@julianoferrasso3 ай бұрын
Excepcional como sempre!! Diego faz um video ensinando a autenticação com JWT com AuthContext no Nextjs 14 🙏🏼🙏🏼
@julianoferrasso3 ай бұрын
Excepcional como sempre!! Diego faz um video ensinando a autenticação com JWT com AuthContext no Nextjs 14 🙏🏼🙏🏼
@pedrobenicio49556 ай бұрын
Excelente resumo. Basicamente agora é só implementar a ideia porque a lógica já está explicada
@arozendojr6 ай бұрын
Parece que o Chrome vai cancelar alguns cookies no navegador, HttpOnly e signed serão cancelados ?
@darlleybrito41986 ай бұрын
Não
@Vitor_NnitivV5 ай бұрын
Eae mano, blz ? Então, eu tava pensando em "reestudar" desenvolvimento web, mesmo que eu já esteja aprendendo ReactJs e TypeScript pra preenche algo que eu tenha não estudado, se você fosse recomenda um guia para estuda desse HTML até chega em ReactJs, TypeScript, nextjs pra eu chega em um nível de poder trabalhar, qual seria ?
@RafaelMarquesOficial6 ай бұрын
Esses cortes fazem parte de alguma live na twitch ou outra plataforma?
@nearkingML6 ай бұрын
Aulao
@douglaslisboa96 ай бұрын
Interessante, mas seguindo a premissa de que se eu der um f12 eu consigo pegar o token, daria pra tentar esconder o token do front-end com a funcionalidade do cross origen que você mencionou em um de seus videos sobre autenticação?
@rafaelsantana5886 ай бұрын
Ao meu ver, todos os métodos de autenticação servem apenas para assegurar que a origem da requisição está sendo de quem realmente era pra ser (do próprio usuário autenticado). Partindo do pressuposto que o próprio usuário pode abrir o dev tools e pegar o token dele (ou um terceiro invade a máquina do usuário), mesmo que o token seja usado indevidamente depois disso, a autenticação fez o que ela tinha que fazer que era assegurar que para ter um token, o usuário precisa provar que é ele: se autenticando com suas credenciais antes. Na minha opinião, daí em diante cabe outras estratégias para serem combinadas com a validação do token, como algum tipo de fingerprint básico do usuário, contendo informações como user agent, ip, e mais algumas informações que deem para de certa forma servir como uma impressão digital do usuário que se autenticou, como forma de “minimizar” o risco de uso indevido. Também caberia uma estratégia de rate-limit (seja a nível de IP ou a nível de ID de usuário, pois também seria possível um usuário mal intencionado (ou como citei, alguém que teve seu dispositivo invadido) utilizar proxies rotativos para fazer flood de requisições com IPs diferentes a cada request). Enfim, fica perceptível que quanto mais proteção, mais vão adicionando camadas extras o que envolve códigos mais complicados e cada vez mais usos de recursos para mitigar a segurança. Como o Diego falou, TUDO é um trade-off. Eu acredito que para 99% das aplicações um JWT de curto prazo (5 minutos de duração, por exemplo) aliado a um refresh token de maior duração (por exemplo, 7 dias, assim se o usuário voltar a usar a aplicação antes de 7 dias do último acesso, ele não vai precisar se autenticar novamente, pois o refresh token vai fazer o trabalho dele). Com essa estratégia, você a nível de backend tem o poder de invalidar o refresh token do usuário a hora que você quiser e ele vai ter no máximo 5 minutos antes de perder acesso total a aplicação. Aí onde tem esses 5 minutos, em uma aplicação mais delicada você pode diminuir ainda mais esse tempo.
@rafaelsantana5886 ай бұрын
Se a aplicação é de alto risco (como aplicações que envolvem transações financeiras), eu adotaria a estratégia do JWT + refresh e um 2FA para todas as requisições delicadas. Mais do que isso eu acho completamente exagerado e uma aplicação que PRECISA de mais do que isso para garantir segurança, eu acho que só um reconhecimento facial muito avançado (que também é burlável se o fraudador estiver muito focado 😂😂). Se até impressão digital tem gente que usa molde de silicone pra “clonar” pra outra pessoa bater ponto no relógio com biometria em órgãos públicos, é a prova de que não existe sistema de segurança perfeito 😂😂😂
@rafaelsantana5886 ай бұрын
Ah, e a resposta da sua pergunta se tem como esconder o token é não. A nível de client side, SEMPRE é possível interceptar/editar qualquer coisa que você envia ou recebe utilizando proxy (como o charles proxy).
@alexandrefernandes60866 ай бұрын
esse cara sabe de algo!!
@yakemsk4 ай бұрын
Cursinho ótimo
@Bilz_-fd1do6 ай бұрын
Que navegador é esse?
@diegocamara37754 ай бұрын
Arc
@Bilz_-fd1do4 ай бұрын
@@diegocamara3775 Vlw!
@lucascipriano35706 ай бұрын
Um caso divertido, o antigo Orkut era na base do CSRF, você conseguia roubar sessões facilmente
@rafaelsantana5886 ай бұрын
😂😂😂😂 voltei no tempo agora… eu devia ter uns 11 anos, achei numa comunidade do Orkut um tutorial de como roubar os cookies de usuários que usavam mozilla firefox na época, pelo que eu me lembro, o usuário só precisava copiar uma url bem cabulosa e colar na barra de endereços e dar enter (clicar não fazia funcionar). Depois disso, não lembro como pois faz muito tempo, mas eu tinha acesso a um código (que agora, parando pra pensar, provavelmente era apenas os cookies) que eu utilizava uma extensão chamada greasemonkey (algo assim) e quando salvava esses dados da vítima na extensão (que devia injetar nos cookies do meu navegador) automaticamente eu tinha acesso ao Orkut dela, e mesmo que ela mudasse a senha, eu continuava com acesso. Felizmente usei só pra trollar alguns amigos e postar scraps falando besteira, teve até um que não gostou e me deu uns cacetes (merecido 😂😂😂). Nunca tinha parado pra pensar que isso era essa técnica de CSRF pois eu só tinha 11 anos e só sabia que simplesmente funcionava 😂😂😂
@chrisaxxwelldev4 ай бұрын
Esqueceu de uma palavra ai no meio em mano
@gabrielgoncalves66726 ай бұрын
Que conteúdo top, Diegao!
@yukiritodops36 ай бұрын
Que maravilha ❤❤
@devcoelho3 ай бұрын
CORS e cookie configurado com o SameSite: Lax já é suficiente pra mitigar o CSRF
@chrisaxxwelldev4 ай бұрын
To vendo geral elogiando ai mais ninguem ta falando a verdade pra galera!!! Fica esperto mano
@chrisaxxwelldev4 ай бұрын
So pra constar jwt tem um macetizinho que ninguem te conta!!! e se você e senior e ainda nao chegou no seu ouvido, provavelmente você nao tem os contatos certos
@joaovitordefrancisco7073 ай бұрын
Habla pa nois então
@gabrielnbds6 ай бұрын
jwt pra auth client server 🤢
@jorgeluizdutraandrade6056 ай бұрын
Qual seria uma alternativa melhor?
@gabrielnbds6 ай бұрын
@@jorgeluizdutraandrade605 session, opaque tokens… jwt tem um caso de uso muito específico onde ele é muito bom (auth entre apis + serviços para client). Não é o caso pra client auth. Não ter revoke já é suficiente pra não usar pra auth do client
@G4m3rSkull6 ай бұрын
Também gostaria de saber, quem sabe você pode gravar um vídeo pra gente ver sua alternativa.