- Navios
- 17 de setembro de 2026 às 01:57 UTC
- Autor
- Kamo
- Enviar
- 034378d
Seguimento para 096feaa1 (As credenciais GoDaddy da organização estavam sendo atendidas por um endpoint que não precisa sessão). Um scan de todos os que encontraram mais 14 colunas. texto cifrado sem guarda Jackson, ao lado de quinze que sempre foram @JsonIgnore: Emprestador.ssnEncriptado, Emprestador.itinEncriptado Activo / Responsabilidade / ReoLien.accountNumberEncriptado PlatformOAuthClient / OrgOAuthClient .secretCiphertext e .extraSecretsCiphertext **************************** (o segredo TOTP) DevMachineAccount.secretCipher **************************** **************************** .refreshTokenCiphertext Todos os quatorze são agora @JsonIgnore. Auditado antes de mudar, na origem/principal de cada repositório que usa estas entidades: cada uma é criptografada e descriptografada apenas em linhas carregadas através do JPA, cada endpoint responde com uma DTO construído à mão ou mapa, corpos de solicitação carregam texto simples que o servidor criptografa, e nada lê o Ciphertext de volta do JSON (sem valor de leitura/convertValue para estes tipos, sem cache do JSON, sem Transferência de serviço a serviço das entidades). Para essas dez entidades, isso não fecha nenhum vazamento vivo — remove a mudança de uma linha (retornando a entidade, ou aninhando-a) que teria aberto uma. @JsonIgnore em vez de WRITE ONLY assim que um corpo de pedido ligado à entidade não pode plantar o texto cifrado também. *************assegura-o por reflexão sobre cada tipo persistente, o caminho JsonbBinding Test Guards jsonb bindings: uma coluna é cifrado quando seu campo diz cifra ou sua coluna diz CIPHER, ENCRITADO ou termina ENC, e deve ser @Jsonignore ou WRITE ONLY. Falhou exactamente nestes catorze. antes da mudança, e seu teste acompanhante comprova que a varredura ainda vê o texto cifrado chamado de quatro maneiras diferentes.