Implementa Header LastModified na Api

[LeandroJatai]

Cria decorator externo à API que aplica nas respostas o Header LastModified.

• De forma padrão, com base na última alteração registrada em AuditLog dos registros pré-filtrados por filterset
• Permite customização no método last_modified_func do decorator, transferido sua chamada para o viewset, podendo assim mudar a abordagem baseada no AuditLog, para algo particular, como é o caso da customização criada como exemplo para matérias legislativas em sapl.api.view_materia._MateriaLegislativaViewSet.last_modified_func que isola o default do decorator e calcula LastModified com base no field data_ultima_atualizacao
• permite o consumidor externo à api fazer consultas enviando "If-Modified-Since" e receber 304 de nada alterado, conforme imagem abaixo.
• adiciona de forma global ao 'axios' no frontend, headers para negar cache pelo navegador de suas poucas chamadas (carece de tratamento adequado com a finalidade de otimização em futuras impl no frontend - sugiro passar para Vite Vue3 antes de qualquer outra nova feature, isto se for mantido o vue em uma futura reformulação)

[edwardoliveira]

Em vez de fazer scraping no AuditLog (o que parece um pequeno hack), talvez possamos utilizar os campos já existentes, como data_ultima_atualizacao em NormaJuridica, MateriaLegislativa, SessaoPlenaria e DocumentoAcessorio, além do campo ultima_edicao em DocumentoAdministrativo e Protocolo.

O código poderia verificar se algum desses atributos está disponível e, caso esteja, ordenar por esse atributo. Se nenhum deles existir, o retorno incluiria todos os registros (ou seja, o query param last_modified seria ignorado).

Isso deixaria a lógica mais simples e direta, e provavelmente atenderia bem aos clientes da API, que em geral estão interessados nas últimas modificações de documentos — e esses já têm esses campos.

Claro, se fizer sentido, podemos também adicionar o campo data_ultima_atualizacao em outros models. O que acha?

[edwardoliveira]

Olá,

Peço um pouco de paciência 🙏 — estou bem enrolado nos últimos meses com uns projetos urgentes de infraestrutura interna de hospedagem do SAPL. Assim que sobrar um tempinho, reviso com calma.

Aproveitando, será que dá pra dar uma olhada na parte de segurança desse PR? A gente teve alguns incidentes recentemente, então seria bom garantir que as mudanças aqui não abram nenhuma brecha ou possível backdoor que possa ser explorado

[LeandroJatai]

Olá @edwardoliveira,

tranquilo, sem pressa...

sobre este comentário: #3808 (comment)
acho que sua intensão era ter feito ele no PR #3809, certo? vou dar maiores informações lá...

sobre os tais incidentes, poderia, talvez em um email ou no telegram, me relatar o ocorrido para eu estar ciente e me prevenir também!?

[LeandroJatai]

sobre este comentário: #3808 (comment)
do PR em si...
só uma correção, não se trata de um query param, é um header no response, e um header no request que, se o client utilizar, evita processo de queryset grandes, realizando apenas uma queryset limit 1 no auditlog... mas... concordo com você que melhor que no auditlog, é no próprio model, pensando nisso é que cito que já fiz um de forma específica, para o próprio model matéria... em sua viewset... vou fazer agora, logo após escrever este comment, os específicos para os principais models em suas respectivas viewsets e fazer com o que o default não realize consultas no auditlog... o PR parece ter muitos arquivos, mas é porque tem um rebuild do frontend, só ignorar o rebuild que fica bem pouca coisa...

[LeandroJatai]

Implementado a forma que verifica se no model do endpoint possui algum dos campos listados, pode adicionar novos campos se necessário na tupla default_fields_for_timestamp.
Mantive o código que acessa o Auditlog, mas ele nunca é acessado, para ativá-lo para Models que não possuem nenhum campo de controle de edição, seria só alterar este retorno.