- Navios
- 27 de agosto de 2026 às 15:42 UTC
- Autor
- Kamo
- Enviar
- ddab3e3
`commerce vendores.uid` é `INT8 DEFAULT unique rowid()` -- cerca de 19 dígitos, onde `Número. MAX SAFE INTEGER ` tem 16. Um ID numérico desse tamanho é um IEEE-754 duplo em um navegador e `JSON.parse` roda-o antes de qualquer código de cliente corre, então o id nomeia um fornecedor que não existe e o selecionador que se envolve um vendedor em uma ordem de trabalho não engaja ninguém, com um 400 que lê como um bug em A conta. Nada atira de ambos os lados. Segurança O serviço já citou um 'Long' fora de alcance na saída -- «JsSafeLongSerializer», abrangido pelos conversores de mensagens MVC `HttpWireJacksonConfig`, deliberadamente não global porque registrá-lo no o mapper compartilhado stringifica os *** IDs de sessão e respostas 401 em toda a plataforma. Então um verdadeiro ID de vendedor chegou ao navegador intacto. O que esse serializador não consegue give is a *stable* type: sua regra é por valor, então um id de 19 dígitos era um JSON string e um de 3 dígitos semeados à mão um número JSON, no mesmo campo, no A mesma resposta. `posApi.Vendor` declarado `uid: número' e estava errado sobre linhas de produção e direita sobre linhas de teste, que é o pior de ambos. Assim, `VendorDTO' digita seus três ids `String' e `toVendorDTO` os encadeia, a regra `ServiceJobApi` e `ServiceTaskBookApi` já declaram. A resposta é agora o mesmo para cada linha e cada valor, que é o que permite que um cliente declare O campo, de todo. `idOrNull` mantém um id nulo ausente em vez de enviar o quatro caracteres "null", que um nu `String.valueOf` faria. «Vendor.uid» permanece uma chave primária «Long» e «POSController» `@PathVariable Long id` ainda liga -- Spring converte o inteiro citado exactamente como converteu o nu. Isto é uma alteração de formato, sem DDL. `VendorWireContract Testa-o, incluindo o serializador de meio intervalo de valor fica errado: um * pequeno * id é citado também.