DynamoDB IncompleteSignatureException

TL;DR — La firma AWS Signature Version 4 della richiesta era incompleta o non conforme agli standard AWS, quindi DynamoDB l'ha rifiutata prima dell'autenticazione. Se utilizzi un AWS SDK la firma è automatica: questo significa quasi sempre una richiesta creata manualmente o un proxy/gateway che ha alterato l'intestazione "Authorization" dopo la firma. Lascia firmare l'SDK e assicurati che nulla riscriva la richiesta in transito.

Cosa significa

IncompleteSignatureException: The request signature does not conform to AWS standards.

AWS firma ogni richiesta con SigV4. Questa eccezione significa che la firma era presente ma componenti richiesti non corretti o mancanti: un'intestazione "Authorization" errata, un'intestazione firmata mancante o una mancata corrispondenza della richiesta canonica. È un HTTP 400, lato client e non riprovabile così com'è: la firma deve essere corretta.

Perché succede

Firma manuale: stai creando tu stesso la firma SigV4 (non tramite un SDK) e la richiesta canonica, l'elenco delle intestazioni firmate o l'intestazione "Autorizzazione" sono errati.
Un'intestazione Authorization non valida: i trigger documentati sono un'intestazione vuota, un parametro Credential o Signature mancante, un'intestazione che non inizia con il nome dell'algoritmo (AWS4-HMAC-SHA256) o una coppia chiave=valore senza un segno di uguale.
Un proxy o un gateway API ha riscritto la richiesta — modificando l'intestazione Authorization (o altre parti firmate) dopo che l'SDK ha firmato, l'intestazione ricevuta da AWS è diversa da quella inviata.
Intestazioni modificate manualmente: l'aggiunta/rimozione di intestazioni dopo la firma o il riordino della stringa di query interrompe la richiesta canonica.

Come risolverlo

Utilizza un AWS SDK ufficiale e lascia che firmi la richiesta. Gli SDK implementano SigV4 correttamente per te: la soluzione per quasi ogni occorrenza è interrompere la firma manuale.
Non modificare la richiesta dopo la firma: se un proxy/gateway si trova in primo piano, assicurati che non aggiunga, elimini o riordini intestazioni o modifichi il corpo/percorso. Firma sul bordo che effettivamente invia la richiesta.
Controlla se l'intestazione Authorization è cambiata durante il transito — Diagnostica documentata di AWS: calcola un hash SHA-256 dell'intestazione inviata, codificalo in Base64 e confrontalo con l'hash incluso in alcuni messaggi IncompleteSignatureException. Se differiscono, qualcosa tra il tuo client e AWS ha modificato l'intestazione.
Se devi firmare manualmente, segui esattamente il processo di firma AWS SigV4: la richiesta canonica, la stringa da firmare, la derivazione della chiave di firma e l'intestazione Authorization (algoritmo, Credential=, SignedHeaders=, Signature=) devono corrispondere. Verificare rispetto a una richiesta SDK sicuramente valida.

Una chiave segreta errata o troncata è un errore diverso: produce una firma completa che non corrisponde, emergendo come "la firma che abbiamo calcolato non corrisponde" anziché questo errore. Allo stesso modo, un orologio macchina distorto emerge come Firma scaduta, non come firma incompleta.

DynoTable + Local

DynoTable utilizza il percorso di firma dell'AWS SDK (nessun SigV4 creato manualmente), quindi questa classe di errore non viene visualizzata nell'uso normale. Se la tua app funziona mentre DynoTable funziona, confronta i profili: Impostazioni → Profili → Verifica connessione con gli stessi tasti caricati dall'app.

Per Local, le credenziali fittizie su un profilo con endpoint "http://localhost:8000" ignorano completamente la firma. Consulta Connetti a AWS e Installa. Una volta risolte le credenziali, eseguire una query di prova del fumo nel Builder di query.

Fonti

Gestione degli errori con DynamoDB — IncompleteSignatureException (verificato il 13-07-2026)
Risoluzione dei problemi relativi alla firma della versione 4 della firma (verificato il 13-07-2026)

FAQ

Che cosa causa un'eccezione IncompleteSignatureException? La firma AWS SigV4 sulla richiesta era malformata o mancavano parti richieste: un'intestazione "Authorization" vuota o malformata, un parametro "Credential" o "Signature" mancante o una coppia chiave=valore senza un segno di uguale. Con un AWS SDK la firma è automatica, quindi di solito significa una firma creata manualmente o un proxy che ha modificato la richiesta dopo la firma.

In cosa differisce da UnrecognizedClientException? IncompleteSignatureException significa che la firma stessa non era valida. UnrecognizedClientException ("il token di sicurezza non è valido") significa che la firma era ben formata ma le credenziali dietro di essa non sono state accettate.

Riproducilo

Invia un'intestazione "Authorization" presente ma non analizzabile come SigV4:

import requests
requests.post(
    'https://dynamodb.us-east-1.amazonaws.com',
    headers={
        'X-Amz-Target': 'DynamoDB_20120810.ListTables',
        'Content-Type': 'application/x-amz-json-1.0',
        'Authorization': 'AWS4-HMAC-SHA256 this-is-not-a-valid-credential-scope',
    },
    data='{}',
)

Produzione reale:

IncompleteSignatureException: Invalid key=value pair (missing equal-sign) in Authorization header (hashed with SHA-256 and encoded with Base64): 'nmoNS1XQjeE7XjC3Nzhi4KfIKrQZsBTlcf+/muyMgDs='.
HTTP 400

La stringa Base64 finale è un hash della tua intestazione, quindi differisce per ogni richiesta: non corrispondere ad essa. Ciò che ti dice il messaggio è strutturale: AWS potrebbe leggere l'algoritmo ma non le coppie Credential=/SignedHeaders=/Signature= dopo di esso. Ciò indica come è stata assemblata l'intestazione, motivo per cui quasi sempre proviene da una firma fatta a mano piuttosto che da un SDK.

Errori correlati

La firma della richiesta che abbiamo calcolato non corrisponde — una firma completa ma errata (chiave segreta errata o canonicalizzazione).
Il token di sicurezza incluso nella richiesta non è valido: firma ben formata, credenziali errate.
Il token di sicurezza incluso nella richiesta è scaduto: credenziali temporanee scadute.
Regione mancante nella configurazione

Riferimenti

Ultima verifica il 13-07-2026 rispetto alla documentazione ufficiale del AWS collegata sopra.

Riprodotto il 26-07-2026 rispetto al servizio live DynamoDB negli Stati Uniti-est-1: l'output sopra è letterale.