Risolvere un errore di orario della firma S3

Leggi Codice e Messaggio esatti della risposta S3 prima di modificare orologio o credenziali. RequestTimeTooSkewed, SignatureDoesNotMatch e un URL prefirmato scaduto descrivono errori diversi. Il gateway dosya attuale emette gli ultimi due casi descritti sotto; non implementa una risposta RequestTimeTooSkewed né una tolleranza documentata per lo scarto dell’orologio nelle richieste normali.

Prima di iniziare: identifica l’errore effettivo

Salva stato e Code/Message XML oscurati di un’operazione fallita, insieme alla versione del client e all’host e percorso effettivi dell’endpoint. L’XML di autenticazione dosya include RequestId (attualmente 0), ma non garantisce un campo diagnostico per l’ora del server o lo scarto massimo. Rimuovi Authorization, segreti S3 e l’intera stringa di query prefirmata da ciò che condividi.

Risposta	Significato nell’implementazione dosya attuale
403 SignatureDoesNotMatch / The request signature does not match	La firma SigV4 ricalcolata è diversa; controlla la coppia del segreto o eventuali modifiche ai dati firmati. Il messaggio da solo non prova che l’orologio sia errato.
403 AccessDenied / Request has expired	Una richiesta prefirmata ha superato l’ora firmata più la scadenza dichiarata.
400 InvalidRequest / X-Amz-Expires is required for presigned requests	La richiesta autenticata tramite query omette una durata di validità obbligatoria.
400 InvalidRequest / X-Amz-Expires must be an integer between 1 and 604800 seconds	La durata dichiarata non è valida; rigenera la richiesta invece di modificarla.
400 InvalidRequest / Invalid X-Amz-Date	La data prefirmata non usa il formato YYYYMMDDTHHMMSSZ del parser.
403 AccessDenied / Missing X-Amz-Date	La richiesta firmata tramite intestazione non ha un timestamp.
403 InvalidAccessKeyId	L’ID di accesso non è valido, è revocato, scaduto o altrimenti indisponibile; sincronizzare l’ora non ripristina la chiave.

L’intervallo verificato per la durata della firma anticipata è 1–604.800 secondi (sette giorni). Il server accetta l’istante esatto di scadenza e rifiuta ogni istante successivo. Il codice attuale per l’autenticazione tramite intestazione non controlla in generale “±5/15 minuti” e quello per la firma anticipata non prevede una finestra di tolleranza per date future. Non contare sulla validità di una vecchia firma nell’intestazione né presumere che qui valga una tolleranza AWS; genera una nuova richiesta a ogni tentativo.

Se il client segnala RequestTimeTooSkewed, verifica che la richiesta di rete sia andata davvero a api.dosya.dev/s3, anziché ad AWS, a un altro servizio o a un proxy. La spiegazione mostrata dal client può riassumere una risposta sottostante diversa. La guida alla risoluzione dei problemi AWS spiega gli errori di firma AWS legati all’orologio, ma non definisce la politica temporale di dosya.

Passaggi: controllare l’ora sul sistema che firma

1. Metti in pausa il processo automatico che fallisce per evitare che reinvii lo stesso contenuto firmato. Individua se la firma avviene sul computer, in un container, su un runner di build o su un server applicativo; correggere l’orologio del browser non ripara una firma creata altrove.
2. Controlla l’ora UTC del sistema. I comandi seguenti mostrano solo ora e stato, senza modificare il sistema:

# macOS or Linux
 date -u '+%Y-%m-%dT%H:%M:%SZ'
# Linux systems that use systemd (not every container has it)
 timedatectl status

# Windows PowerShell
(Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
w32tm /query /status

3. Confrontala con una fonte oraria attendibile usata dalla tua organizzazione. UTC rappresenta lo stesso istante in ogni fuso orario; cambiare solo il fuso visualizzato non sincronizza l’orologio. L’intestazione HTTP Date di un server può aiutare a rilevare differenze grossolane, ma non è un servizio autorevole di sincronizzazione e proxy o cache possono renderla fuorviante.
4. Se l’ora è errata, usa l’impostazione automatica supportata dal sistema operativo o il servizio orario dell’amministratore. Su macOS, Data e ora offre data e ora automatiche; su Windows, Data e ora offre i controlli di sincronizzazione; su Linux con systemd controlla lo stato NTP riportato. Dispositivi gestiti, VM e container possono richiedere l’intervento dell’amministratore dell’host. Ricontrolla l’output UTC dopo la modifica.

Questi comandi possono richiedere un servizio o un permesso sulla tua piattaforma. Un comando timedatectl o w32tm fallito non prova che le credenziali dosya siano invalide. Mantieni sincronizzato il sistema che firma senza disattivare la verifica HTTPS o ampliare i permessi della chiave.

Passaggi: inviare un nuovo test firmato di sola lettura

Usa un profilo AWS CLI v2 configurato correttamente, qui chiamato dosya-help-check. Deve contenere la coppia ID di accesso e segreto S3, con us-east-1 e s3.addressing_style impostati su path. Ottieni la coppia da Profilo → Chiavi API, espandi una chiave abilitata a S3 e scegli credenziali S3 → Attiva; il segreto è disponibile solo nella finestra di generazione. Per la diagnosi usa una chiave Solo lettura, vincolata al tuo spazio di lavoro e abilitata al gateway S3. Anche il tuo ruolo deve consentire S3 e l’elenco.

Configura il profilo in modo interattivo con aws configure --profile dosya-help-check invece di passare il segreto come argomento della shell. Non sovrascrivere mai un profilo esistente non correlato. Imposta l’indirizzamento path con aws configure set s3.addressing_style path --profile dosya-help-check. Sostituisci ws_example sotto con il Bucket da Integrazioni → S3:

aws --profile dosya-help-check --region us-east-1 --endpoint-url https://api.dosya.dev/s3 s3api list-objects-v2 --bucket ws_example --max-keys 1 --no-paginate

L’esecuzione di questo comando firma una nuova richiesta; riprovare un URL prefirmato salvato non lo fa. Aspettati una pagina di elenco, eventualmente senza Contents se la posizione è vuota, e un codice di uscita CLI pari a zero. Un elenco di sola lettura non sovrascrive né elimina file. Se il risultato diventa un rifiuto per protocollo, ruolo, IP, orari attivi o utilizzo, il sintomo relativo a ora o firma è risolto, ma occorre correggere separatamente la configurazione di accesso. La chiave non può superare i permessi del ruolo; non serve un piano superiore solo per correggere la firma, anche se valgono limiti sul numero di chiavi e quote ordinarie.

Link prefirmati, proxy e firme non corrispondenti

URL scaduto. Chiedi all’applicazione attendibile che lo ha generato di crearne un altro dopo aver corretto l’ora del sistema che firma. Non estendere X-Amz-Expires, riscrivere X-Amz-Date o togliere parametri a mano: quei valori fanno parte della firma. Un URL prefirmato contiene credenziali; condividilo solo con il destinatario previsto e non incollarlo mai nella diagnostica pubblica. La rigenerazione produce un nuovo URL, non un link di condivisione pubblico permanente dosya. Anche la revoca della credenziale principale rimuove l’accesso.

L’orologio è corretto ma SignatureDoesNotMatch persiste. Abbina l’ID DOSYA… al segreto generato per quella chiave esatta. Verifica che l’endpoint includa /s3, che l’indirizzamento path sia attivo e che metodo firmato, percorso dell’oggetto, query codificata, intestazione Host e intestazione dell’hash del contenuto arrivino invariati. Un proxy che riscrive uno qualsiasi dei componenti firmati può invalidare la firma. Controlla quale profilo sceglie il processo che fallisce; i comandi senza l’opzione esplicita --profile possono usare credenziali dell’ambiente. Controlla privatamente le origini previste con aws configure list --profile dosya-help-check.

Richiesta in cache o ripetuta. Disattiva il riuso delle intestazioni Authorization o degli URL prefirmati salvati e lascia che l’SDK firmi ogni richiesta al momento dell’invio. Reinviare gli stessi byte mantiene la vecchia scadenza. Se provi l’accesso diretto senza proxy, confronta il comportamento usando una nuova firma su ogni percorso, senza trasferire una firma tra host diversi.

Segreto perso o esposto. S3 Attive · mostra non può recuperare il segreto. Se lo hai perso senza sospetta esposizione, crea credenziali sostitutive, aggiorna il sistema che firma, verifica la sostituzione e poi revoca la vecchia chiave. Se sospetti un’esposizione, revoca prima la chiave API esposta e accetta un’interruzione temporanea dei client; non lasciarla attiva mentre verifichi la sostituzione. La revoca è irreversibile e coinvolge ogni client che usa quella chiave o coppia, ma lascia intatti i file nel cloud. L’invalidazione della cache inizia alla revoca, ma altri ambienti isolati o cache periferiche possono conservare temporaneamente l’autorizzazione; verifica che la vecchia credenziale sia rifiutata con una richiesta innocua di sola lettura. Non ruotare le chiavi degli altri client solo perché una richiesta era malformata.

Risultato previsto

Una nuova richiesta di sola lettura riesce sul bucket dosya previsto oppure restituisce un rifiuto di accesso preciso, diagnosticabile separatamente. Non è stata necessaria alcuna modifica ai dati per verificare la firma. Registra privatamente sistema che firma, endpoint e timestamp corretti affinché il processo pianificato usi la stessa configurazione la prossima volta.

Guide correlate

• Profilo AWS CLI e test di trasferimento
• Campi di connessione S3 e limiti dei permessi
• Risolvere altri problemi di accesso S3