3740
🔥Desde 2016! 💥O maior e mais ativo grupo de .NET do Telegram há 9 anos. 🎯Grupo sobre .NET, ASP.NET, Mono, .NET Core, Xamarin, C# etc. Use /info para as regras e informações adicionais. 👉Regras: go.gaGO.io/dotnetbr-rules
Requisitos diferentes pedem soluções diferentes. Temos alguns poucos apps mobile aqui (acho que uns 3, no máximo) e não sei como é implementado esse requisito neles, nem sei se são aplicados. Os sistemas que minha área é responsável são, em geral, de utilização em PC e, independentemente do fato de o usuário estar no celular ou no PC, a mudança de rede deve barrar a requisição
Читать полностью…
🔵 [Online|11:50|.NET 10: melhorias manipulação datas|Gratuito]
Fala galera! Daqui a pouco - a partir das 11:50 - horário de Brasília - estreia mais um vídeo gratuito - com chat ao vivo para dúvidas - no Canal .NET. Confira neste conteúdo mais novidades do .NET 10 -> melhorias envolvendo a manipulação de datas (novas sobrecargas de métodos) com o tipo ISOWeek: https://www.youtube.com/watch?v=qqoAFTTC3nY
cara eu consegui resolver, era um bug que a ia do próprio n8n estava requisitando um chat sendo que eu estava usando um webhook para a mensagem chegar via postman
Читать полностью…
Aqui tb, todo token tem um id de sessão, se o IP mudar ou for de uma nova instância ambas caem.
Читать полностью…
Alguém já passou por situação parecida e tem ideia de alguma solução que seja melhor?
Читать полностью…
Fluxo Detalhado de Autenticação com Access Token e Refresh Token:
parei para reler sobre autenticação e refresh token, são poucos parágrafos e é uma boa leitura.
O processo de autenticação e autorização utilizando access tokens e refresh tokens inicia-se com o login do usuário. O usuário submete suas credenciais (nome de usuário e senha) para o backend da aplicação. O backend, por sua vez, autentica essas credenciais, verificando-as em um banco de dados de usuários ou em um provedor de identidade configurado. Em caso de autenticação bem-sucedida, o backend prossegue com a geração de um access token e um refresh token.Читать полностью…
O access token é enviado para o frontend da aplicação, tipicamente no corpo da resposta HTTP. Este token possui uma validade limitada, geralmente de curta duração, para mitigar os riscos de segurança em caso de comprometimento. Já o refresh token é armazenado de forma segura no backend, frequentemente em um banco de dados associado ao usuário autenticado. Em algumas implementações, o refresh token também pode ser enviado para o frontend como um cookie HTTP-only, adicionando uma camada extra de segurança contra ataques de Cross-Site Scripting (XSS).
Para acessar recursos protegidos na plataforma, o frontend deve incluir o access token em todas as requisições HTTP enviadas ao backend. Isso é comumente feito adicionando o access token ao cabeçalho Authorization da requisição, utilizando o esquema Bearer. O backend, ao receber uma requisição para um recurso protegido, verifica a validade do access token presente no cabeçalho. Se o token for válido e não tiver expirado, o backend processa a requisição e retorna a resposta apropriada.
Devido à sua curta duração, o access token eventualmente expira. Quando isso ocorre, o frontend não consegue mais utilizar o access token expirado para acessar recursos protegidos, geralmente recebendo uma resposta de erro de autenticação, como um código de status 401 Unauthorized. É nesse ponto que o refresh token entra em ação. O frontend, ao detectar a expiração do access token, utiliza o refresh token para solicitar um novo access token ao backend. Essa solicitação é enviada para um endpoint específico no backend, dedicado à renovação de tokens.
O backend, ao receber um refresh token, realiza uma série de validações. Primeiramente, verifica se o refresh token é válido e não foi revogado. Em seguida, associa o refresh token ao usuário correto, consultando o armazenamento seguro onde foi guardado. Se o refresh token for considerado válido, o backend emite um novo access token para o frontend. Em muitas implementações, juntamente com o novo access token, um novo refresh token também é gerado e enviado ao frontend, substituindo o refresh token anterior. Essa prática, conhecida como rotação de refresh token, aumenta a segurança do sistema, pois limita o tempo de uso de um refresh token comprometido.
O processo de logout do usuário envolve a invalidação dos tokens de acesso e de refresh. No frontend, ao realizar o logout, o access token deve ser removido da memória ou do armazenamento local. No backend, o refresh token associado ao usuário deve ser invalidado, por exemplo, marcando-o como revogado no banco de dados. Essa invalidação impede que o refresh token seja utilizado para obter novos access tokens, garantindo que a sessão do usuário seja encerrada de forma segura.
o principal e mais complexo é definir o número de versão.
Читать полностью…
Entendi, onde trabalho é muito burocracia para fazer isso.
Читать полностью…
faz parte do publish atualizar a imagem docker (que tem uma versão) e usar o mesmo número de versão (que na verdade é o nome da tag do git) como variável de ambiente.
Читать полностью…
troquei a fonte direto no html para ficar mais visível.
Читать полностью…
Isso não pode ser feito por humanos, é falho, frágil.
Читать полностью…
Preciso exibir na tela informações como branch da release, horário do commit e autor.
Atualmente tenho um arquivo .json que atualiza sempre que a aplicação roda em Develop, porem o horário do commit nem sempre será exato.
Queria fazer a atualização do arquivo no momento que o commit for executado para aumentar a precisão do horário.
Vou fazer um stream de teste aqui pq preciso identificar
Consegui voltar e milagrosamente nada deu errado, exceto o whiteboard que tá me irritando faz tempo.
Acabei de testar 1 dos nossos apps e o comportamento é esse mesmo. Se o usuário mudar de rede, a sessão é finalizada
Читать полностью…
Se o usuário puder usar seu sistema no celular ele pode ter saído do wi-fi e ir para internet do celular e vice versa
Читать полностью…
então acabei optando por usar http request pra chamar a key de uma IA free
Читать полностью…
Interessante... aqui a gente barra request de IP diferente do registrado no token, mas nunca pensei em invalidar... mas faz sentido, porque se tá com IP diferente, provavelmente o token foi vazado
Читать полностью…
Eu estou para refazer algumas partes da arquitetura da plataforma para alunos, e parei para dar uma lida sobre boas práticas.
Читать полностью…
Muito show! Ainda não tinha visto uma explicação tão sucinta e boa ao mesmo tempo.
No caso dos sistemas onde trabalho, existe uma exigência de segurança que proíbe 2 seções simultâneas do mesmo usuário, em qualquer hipótese. Pra isso, a solução adotada atualmente é armazenar o access token do usuário em banco de dados e verificar se ele ainda não foi invalidado em cada requisição, assim como explicaste sobre o refresh token. Isso faz com que as requisições demorem mais um pouco, mas é necessário, pois a área de segurança da informação não admite nem a eventual existência de 2 access tokens válidos, independentemente do quão curtos são os tempos de expiração
Estava pensando nisso. Não sei se é possível realizar a atualização de uma variável de esteira no momento do build apenas em produção e incrementar o valor dela.
Читать полностью…
O que eu faço manualmente é definir uma tag, mas daí pra frente, é a pipeline quem faz.
Читать полностью…
A data/hora me assegura se estamos diante de uma versão presa no cache ou não.
Читать полностью…
Essas informações vem de um arquivo ou estão em variáveis de ambiente ou esteira?
Читать полностью…
⚫ [Ao Vivo|21h|Dicas Bancos Dados|Gratuito]
Fala galera! Daqui a pouco - por volta das 21:00 - horário de Brasília - teremos mais um evento ONLINE e GRATUITO no Canal .NET. Desta vez uma nova live em que serão abordadas dicas, ferramentas, frameworks e soluções úteis no desenvolvimento de aplicações que trabalhem com tecnologias bancos de dados... SQL Server, Azure SQL, PostgreSQL, MySQL e muito mais! Segue o link para da transmissão: https://www.youtube.com/watch?v=i9msy2qySxs