URL pre-firmati e x-amz-acl

Question

Desidero creare un cosiddetto URL "pre-firmato" per caricare un oggetto particolare (PUT) nel bucket Amazon S3.

Fin qui tutto bene. Sto usando la libreria python boto per creare un URL, che contiene tutte le cose necessarie (scadenza, firma e così via). L'URL è simile al seguente:

https://<bucketname>.s3.amazonaws.com/<key>?Signature=<sig>&Expires=<expires>&AWSAccessKeyId=<my key id>&x-amz-acl=public-read

Nota l'ultimo parametro.

Questo, almeno, a quanto ho capito, limita chiunque usi questo URL per caricare un oggetto su una particolare chiave in un determinato bucket e limita anche l'ACL in scatola che verrà impostato sull'oggetto su "public-read".

La mia ultima affermazione è abbastanza scorretta.

Come si è visto, se si utilizza questo URL, è possibile effettuare le seguenti operazioni con l'x-AMZ-ACL intestazione (in contrapposizione al query di parametro di stringa con lo stesso nome, che si must impostato per il corretto controllo della firma):

1. Impostarlo su "public-read". Le autorizzazioni dell'oggetto sono costituite da due voci: "lettura" per "Everyone" e "controllo completo" per il proprietario del bucket. Questo è abbastanza prevedibile.
2. Omettere l'intestazione x-amz-acl. Le autorizzazioni sull'oggetto saranno le stesse del default per bucket (il proprietario del bucket ha il controllo completo). Perché?
3. Impostarlo su "public-read-write". Il risultato è esattamente come in (1).
4. Impostarlo su "lettura autenticata". Gli "utenti autenticati" ottengono l'autorizzazione di "lettura", il proprietario del bucket ha il controllo completo.
5. Impostarlo su "bucket-owner-read". Il risultato è esattamente come in (2). Il proprietario del bucket ha il controllo completo, non sono definite altre autorizzazioni.
6. Impostarlo su "bucket-owner-full-control". Non sorprende che il proprietario della benna avrà il pieno controllo.
7. Impostarlo su un nome ACL predefinito non esistente e ottenere un errore.

Così sembra, che

1. L'x-AMZ-ACL intestazione non prende parte alla verifica della firma, perché si può cambiare a piacimento e la richiesta riesce. Il parametro stringa di query, tuttavia, è sicuramente è preso in considerazione durante il controllo della firma.
2. x-amz-acl parametro stringa di query non influenza le autorizzazioni dell'oggetto direttamente, come in, non fa nulla da solo.
3. Se si invia un colpo di testa x-AMZ-ACL, le autorizzazioni risultanti mai essere
   • più restrittiva per il proprietario del secchio, di quanto lo siano per impostazione predefinita.
   • meno restrittiva per il proprietario non-secchio.
4. Possono, tuttavia, essere più restrittivo per il proprietario non-bucket. Cioè, se si specifica x-amz-acl=public-read nella stringa di query, è possibile impostare l'intestazione x-amz-acl-authenticated-read e invece di un oggetto leggibile pubblicamente ottiene un oggetto, che può essere letto solo da utenti autenticati.

Qual è il vero relazione tra il parametro QS x-AMZ-ACL e l'intestazione, che va sotto lo stesso nome? C'è un modo per limitare le autorizzazioni sull'oggetto, che deve essere caricato tramite una richiesta PUT a un cosiddetto URL "pre-firmato"?

Answer 1

Come ho capito (e potrei essere sbagliato qui), l'intestazione x-amz-acl ha la priorità sull'argomento querystring - e hanno lo stesso scopo. Il motivo per cui solo il parametro querystring viene preso in considerazione durante il controllo della firma è semplicemente dovuto al fatto che le intestazioni non fanno parte del controllo della firma per la politica.

This page potrebbe aiutare; mi ha aiutato molto durante la creazione di moduli da caricare direttamente su S3.

Answer 2

Sembra che si stia utilizzando il nome errato per il parametro acl. Secondo la loro guida sulle richieste di firma, prova a utilizzare ACL:

Signing and Authenticating REST Requests

Se la richiesta si rivolge a un sub-risorsa, come il controllo delle versioni, l'ubicazione, ACL, torrente, ciclo di vita, o?????? versionid aggiunge la sotto-risorsa, il suo valore se ne ha una e il punto interrogativo. Si noti che in caso di più risorse secondarie, le risorse secondarie devono essere ordinate lessicograficamente in base al nome di sottoreport e separate da "&". per esempio. ? acl & versionId = valore.

L'elenco delle sotto-risorse che deve essere incluso quando si costruisce la CanonicalizedResource Element sono: ACL, ciclo di vita, l'ubicazione, la registrazione, la notifica, Kem, la politica, requestPayment, torrente, uploadId, upload, VERSIONID, controllo delle versioni, le versioni e sito web .