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

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 KZread é a solução do meu problema kkkkk

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.

@matheuspassos8650

3 ай бұрын

up!

@MarioHenriquePolewacz

3 ай бұрын

UP 2 !

@RafaelGomes01

3 ай бұрын

UP 3 😅

@DiogoMoreira0610

3 ай бұрын

up 4

@lucasdeandradeoficial

3 ай бұрын

...com a parte do Refresh Token também esta faltando

Excepcional como sempre!! Diego faz um video ensinando a autenticação com JWT com AuthContext no Nextjs 14 🙏🏼🙏🏼

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

Excelente resumo. Basicamente agora é só implementar a ideia porque a lógica já está explicada

Explicação muito boa man 👏🏻👏🏻👏🏻

Que conteúdo top, Diegao!

Que maravilha ❤❤

esse cara sabe de algo!!

Cursinho ótimo

Aulao

Essas lives acontecem aonde?

Deveria ter um video fzd uma tela auth com React puro junto com auth de rotas publicas e privadas

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?

Esses cortes fazem parte de alguma live na twitch ou outra plataforma?

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 ?

CORS e cookie configurado com o SameSite: Lax já é suficiente pra mitigar o CSRF

up pra fazerem um vídeo com autenticação jwt + nextjs14

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í.

@maykonsousa84

3 ай бұрын

Eu uso o next-auth ou clerk que já gerencia isso tudo via cookies, inclusive com login social

@bonk1463

3 ай бұрын

@@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.

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?

@rafaelsantana588

3 ай бұрын

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.

@rafaelsantana588

3 ай бұрын

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 😂😂😂

@rafaelsantana588

3 ай бұрын

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).

Parece que o Chrome vai cancelar alguns cookies no navegador, HttpOnly e signed serão cancelados ?

@darlleybrito4198

3 ай бұрын

Não

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?

@u9s0e9r

3 ай бұрын

Vc pode proteger as paginas que vc quiser com conditional rendering.

@GustavoAlves-pf7lf

3 ай бұрын

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.

@ryanpantaneiro

2 ай бұрын

obrigado, meus manos!!

No começo eu não tava entendendo..no final parecia que eu tava no começo kkkk obs: sou iniciante

Um caso divertido, o antigo Orkut era na base do CSRF, você conseguia roubar sessões facilmente

@rafaelsantana588

3 ай бұрын

😂😂😂😂 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 😂😂😂

@chrisaxxwelldev

Ай бұрын

Esqueceu de uma palavra ai no meio em mano

Que navegador é esse?

@diegocamara3775

Ай бұрын

Arc

@Bilz_-fd1do

Ай бұрын

@@diegocamara3775 Vlw!

To vendo geral elogiando ai mais ninguem ta falando a verdade pra galera!!! Fica esperto mano

@chrisaxxwelldev

Ай бұрын

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

@joaovitordefrancisco707

27 күн бұрын

Habla pa nois então

jwt pra auth client server 🤢

@jorgeluizdutraandrade605

3 ай бұрын

Qual seria uma alternativa melhor?

@gabrielnbds

3 ай бұрын

@@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

@G4m3rSkull

3 ай бұрын

Também gostaria de saber, quem sabe você pode gravar um vídeo pra gente ver sua alternativa.

@chrisaxxwelldev

Ай бұрын

hahaha

Excepcional como sempre!! Diego faz um video ensinando a autenticação com JWT com AuthContext no Nextjs 14 🙏🏼🙏🏼