Problema:

Atualmente, os dados sensíveis, como CPF e CNPJ, estão sendo armazenados no banco de dados em formato puro, o que representa uma vulnerabilidade significativa. Em caso de vazamento de dados, informações pessoais podem ser expostas, colocando em risco a privacidade dos usuários.

Proposta:

Implementar mecanismos de segurança para proteger os dados sensíveis, incluindo:

• Criptografia: Utilizar algoritmos de criptografia fortes para cifrar os dados antes de armazená-los no banco de dados.
• Mascaramento: Aplicar técnicas de mascaramento para ocultar parte dos dados sensíveis, como os dígitos centrais do CPF e CNPJ, durante a exibição ou em relatórios.
• Controle de acesso: Restrigir o acesso aos dados sensíveis apenas aos usuários autorizados e com necessidade de conhecer essas informações.
• Logs de auditoria: Registrar todas as operações realizadas sobre os dados sensíveis para fins de auditoria e investigação.

Benefícios:

• Maior segurança: Proteção dos dados sensíveis contra acessos não autorizados.
• Conformidade com leis de proteção de dados: Cumprimento com as legislações vigentes, como a LGPD.
• Redução de riscos: Minimização dos riscos de vazamento de dados e consequentes danos à reputação da empresa.

Possiveis Tarefas:

• Escolha do algoritmo de criptografia: Avaliar os algoritmos de criptografia mais adequados para o contexto da aplicação e escolher um que ofereça um bom equilíbrio entre segurança e desempenho.
• Implementação da criptografia: Integrar a criptografia no processo de inserção e recuperação dos dados sensíveis no banco de dados.
• Definição das regras de mascaramento: Estabelecer as regras de mascaramento para os diferentes tipos de dados sensíveis.
• Implementação do controle de acesso: Configurar as permissões de acesso aos dados sensíveis de acordo com os papéis dos usuários.
• Configuração dos logs de auditoria: Implementar um sistema de log para registrar as operações realizadas sobre os dados sensíveis.

Ao fazer uma consulta que deveria retornar um status code 404, o endpoint devolve uma resposta com com os objetos _links e page.

Comportamento esperado

Retornar um status code 404

Passos para reproduzir

Chamar o endpoint com uma busca que não renorna resultados, como a seguir:
https://buddy.propresto.app/api/v1/pets?ageRange=10%2B+anos&page=0&size=8

Contexto

Preciso tratar os status codes no frontend para poder mostrar uma resposta adequada ao usuário.

Descrição:

Atualmente, o sistema utiliza URLs externas para as imagens dos pets, o que limita o controle e a qualidade das imagens.

Problema:

• Dependência externa: A aplicação depende de fontes externas para exibir as imagens, o que pode causar instabilidade.
• Falta de controle: Não há como garantir a qualidade e o formato das imagens antes de serem exibidas na plataforma.
• Limitação de formatos: A aplicação está restrita aos formatos de imagem suportados pelas URLs.

Proposta:

Implementar um sistema de upload direto de imagens para a aplicação, permitindo maior controle e flexibilidade no gerenciamento das imagens dos pets.

Benefícios:

• Controle total: A aplicação terá controle sobre as imagens, permitindo validações e transformações.
• Qualidade garantida: Será possível garantir a qualidade das imagens antes de armazená-las.
• Flexibilidade: Suporte a diversos formatos de imagem.
• Independência: A aplicação não dependerá mais de fontes externas.

Tarefas:

• Escolha da estratégia de armazenamento: Avaliar opções como banco de dados, armazenamento em nuvem (AWS S3, Google Cloud Storage) ou sistema de arquivos local.
• Desenvolvimento da funcionalidade de upload: Criar a interface para o usuário enviar as imagens e o backend para processar e armazenar os arquivos.
• Adaptação da aplicação: Ajustar o código para utilizar os novos arquivos armazenados em vez das URLs.
• Exibição das imagens: Garantir a exibição correta das imagens na aplicação.

Considerações:

• Segurança: Implementar medidas de segurança para proteger as imagens armazenadas.
• Otimização: Otimizar as imagens para a web para melhorar o desempenho.
• Formatos suportados: Definir os formatos de imagem permitidos.
• Limites de tamanho: Estabelecer um limite para o tamanho dos arquivos.

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/7

Atualmente as mensagens de erro de campos obrigatórios nas requisições estão nesse formato: [nome do campo] of mandatory [entidade]
O que dá a entender que a entidade é obrigatória, e não o campo.
Exemplos desses casos com as sugestões de correção:

#77 (review)

Entendo que essa correção não deve ser feita no mesmo contexto da feature de avatar do pet, ou da feature de state do cadastro do pet, pois possui um escopo próprio independente destes assuntos, razão pela qual abri uma issue especifica para aplicar as correções sugeridas.

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/5

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/6

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/1

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/9

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/8

Acho interessante que o avatar do pet seja obrigatório, para que os usuários que pretendem adotar um pet possam rapidamente ver as caracteristicas dos pets disponíveis para adoção.

Para tornar isso possível é necessário:

• Adicionar validações de que ao fazer uma requisição para /v1/pets/register se o campo avatar do corpo da requisição for null ou blank, retorne Bad Request.
• Fazer o ORM realizar um join entre a coluna avatar da tabela PET e a coluna id da tabela PET_IMAGE, garantindo assim que o avatar seja uma imagem válida.
• Criar uma constraint de Not Null na coluna avatar da tabela PET.

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/3

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/4

Tracking issue for:

• https://github.com/hywenklis/buddy-api/security/code-scanning/2

Ao fazer uma consulta com sort baseado na propriedade createdAt, o servidor retorna o seguinte erro:

There was an unexpected error (type=Internal Server Error, status=500).
No property 'createdAt' found for type 'PetEntity'

Comportamento esperado

Retornar a lista de animais ordenada pela data de criação.

Passos para reproduzir

Chamar o endpoint passando como argumento de ordenação a propriedade createdAt, como a seguir:
https://buddy.propresto.app/api/v1/pets?&size=8&sort=createdAt,asc

Contexto

Gostaria de poder ordenar os animais em ordem de criação para poder mostrar os registros mais novos primeiro.

Descrição

Precisamos criar testes unitários e integrados para garantir a qualidade e confiabilidade do código, bem como para alcançar uma cobertura de testes satisfatória. Estes testes devem cobrir os principais cenários de uso e casos extremos, garantindo que todas as funcionalidades funcionem conforme o esperado.

Objetivos

1. Testes Unitários:

   • Escrever testes unitários para todos os métodos e funções principais.
   • Garantir que cada unidade de código (método/função) funcione isoladamente.

2. Testes Integrados:

   • Escrever testes integrados que validem a interação entre diferentes componentes do sistema.
   • Garantir que a integração entre diferentes módulos esteja funcionando corretamente.

Cenários de Teste

Os seguintes cenários de teste devem ser considerados:

1. Cenários Positivos:

   • Verificar que o comportamento esperado ocorre para entradas válidas.

2. Cenários Negativos:

   • Verificar o comportamento do sistema para entradas inválidas ou inesperadas.

3. Casos Extremos:

   • Testar limites superiores e inferiores de entradas.

4. Fluxos Alternativos:

   • Verificar comportamentos alternativos e exceções.

Tarefas

• Identificar componentes/módulos que precisam de testes.
• Escrever testes unitários para cada componente/módulo identificado.
• Escrever testes integrados para verificar a interação entre os componentes.
• Configurar ferramentas de cobertura de testes e garantir que a cobertura atinja os padrões definidos.

Critérios de Aceitação

• Testes unitários e integrados escritos e revisados.
• Cobertura de teste adequada (definir um percentual mínimo, se necessário).
• Nenhum bug crítico encontrado durante a execução dos testes.

Notas Adicionais

Qualquer dúvida ou problema encontrado durante a criação dos testes deve ser discutido na seção de comentários desta issue.

Autor: @hywenklis
Data de Criação: 14/07/2024

Problema:

Atualmente, o sistema está limitado a aceitar apenas CPF como documento de identificação, o que restringe a base de usuários. É necessário flexibilizar o campo para permitir a inclusão de outros documentos, como RG e CNPJ.

Relacionamento com a Issue #60:

Essa issue está diretamente relacionada à Issue #60 - "Implementar criptografia e mascaramento para dados sensíveis (CPF e CNPJ)". A ampliação dos tipos de documentos aceitos exige que as medidas de segurança implementadas na issue anterior sejam estendidas para os novos tipos de documentos.

Proposta:

• Unificar o campo: Criar um campo único para identificar o tipo e o número do documento (CPF, RG, CNPJ).
• Validar os dados: Implementar validações para garantir que o formato do documento seja válido.
• Adaptar a criptografia e o mascaramento: Extender as regras de criptografia e mascaramento para os novos tipos de documentos.
• Atualizar a interface do usuário: Ajustar a interface para permitir a seleção do tipo de documento e a entrada dos dados correspondentes.

Benefícios:

• Maior abrangência: Aumento da base de usuários ao permitir o cadastro com diferentes tipos de documentos.
• Flexibilidade: Adaptação do sistema para atender a diferentes necessidades.
• Melhoria da experiência do usuário: Interface mais intuitiva e completa.

Tarefas:

• Definir os tipos de documentos suportados: Elaborar uma lista completa dos documentos que serão aceitos.
• Adaptar o modelo de dados: Ajustar o modelo de dados para armazenar o tipo e o número do documento.
• Implementar as validações: Criar regras de validação para cada tipo de documento.
• Atualizar a interface: Modificar a interface para permitir a seleção do tipo de documento e a entrada dos dados correspondentes.
• Adaptar a lógica de negócios: Ajustar a lógica de negócios para lidar com os diferentes tipos de documentos.

Considerações:

• Compatibilidade com sistemas externos: Verificar a compatibilidade com sistemas externos que utilizam os dados de identificação.
• Legislação: Verificar as legislações específicas para cada tipo de documento e garantir a conformidade.

Essa issue complementa a Issue #60 e visa garantir que a aplicação seja mais inclusiva e segura.