Avaliar a adição do UID como um parâmetro em todos os endpoints para recusar requisições de dispositivos bloqueados

[manoelcampos]

Somente alguns endpoints REST recebem o UID do dispositivo.
Neste caso, se o dispositivo estiver bloqueado, a requisição é recusada.
Mas o dispositivo poderá continuar consultando outros endpoints que não recebem o UID.
Então, pode-se incluir o UID e a autenticação do CAPTCHA em todos os endpoints.
Mas como o frontend também precisa acessar os endpoints, ele pode ser cadastrado como um dispositivo.

É preciso avaliar a implementação ou não da issue, por questões de tempo e prioridades e analisar se realmente faz sentido.

[radaelilucca]

Essa questão pode ser resolvida com implementação do JWT, e quanto ao frontend podemos cadastrar o utilizador, exatamente como na #97, daí adicionamos um middleware de auth para todas as rotas.

Quando implementado, podemos extrair o UID do dispositivo do payload do JWT, dai não precisamos passar UIDs em todas as chamadas.

[manoelcampos]

Ótimo. Então poderíamos usar o UID e o código do captcha (que seria a "senha") para gerar o token JWT.
Assim, se for detectado abuso por parte de algum dispositivo, podemos forçar o app a exibir o captcha novamente pra trocar o código ou bloquear o dispositivo no banco.

Vi que a versão 3 do reCAPTCHA poderia ser usada pra isso e nem ao menos exige interação do usuário,
mas optamos por uma solução mais simples. Minha dúvida é se a versão 3 funciona no iOS, pois pelo que li
na documentação, ele integra com o Google Play Services no Android.

[manoelcampos]

Mas ainda tem um problema co mo reCAPTCHA 3. Ele é usado para evitar bots, sem que o usuário tenha que resolver um desafio antes. O problema é que o nosso próprio app é um bot 😆, então não imagino que o reCAPTCHA 3 vá resolver alguma coisa.

[manoelcampos]

A não ser que tenha como ele apenas aceitar requisições vindas do nosso app, como é possível com a API do Maps.