Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
I seguenti argomenti sono utili per risolvere alcuni problemi CORS comuni relativi a S3.
Argomenti
Errore 403 Accesso negato: CORS non è abilitato per questo bucket
Il seguente errore 403 Forbidden
si verifica quando viene inviata una richiesta multiorigine ad Amazon S3 ma CORS non è configurato sul bucket S3.
Errore: HTTP/1.1 403 Accesso negato Risposta CORS: CORS non è abilitato per questo bucket.
La configurazione CORS è un documento o una policy con regole che identificano le origini che potranno accedere al bucket, le operazioni (metodi HTTP) supportate per ogni origine e altre informazioni specifiche dell'operazione. Scopri come configurare CORS su S3 utilizzando la console AWS SDKs Amazon S3 e l'API REST. Per ulteriori informazioni su CORS ed esempi di configurazione CORS, consulta Elementi di CORS.
Errore 403 Accesso negato: questa richiesta CORS non è consentita
Il seguente errore 403 Forbidden
viene ricevuto quando una regola CORS nella configurazione CORS non corrisponde ai dati nella richiesta.
Errore: HTTP/1.1 403 Accesso negato Risposta CORS: questa richiesta CORS non è consentita.
Di conseguenza, questo errore 403 Forbidden
può verificarsi per diversi motivi:
-
L'origine non è consentita.
-
I metodi non sono consentiti.
-
Le intestazione richieste non sono consentite.
Per ogni richiesta ricevuta da Amazon S3, è necessario disporre di una regola CORS nella configurazione CORS che corrisponda ai dati nella richiesta.
L'origine non è consentita
L'intestazione Origin
di una richiesta CORS al bucket deve corrispondere alle origini dell'elemento AllowedOrigins
nella configurazione CORS. Un carattere jolly ("*"
) nell'elemento AllowedOrigins
corrisponderà a tutti i metodi HTTP. Per ulteriori informazioni su come aggiornare l'elemento AllowedOrigins
, consulta Configuring cross-origin resource sharing (CORS).
Ad esempio, se nell'elemento AllowedOrigins
è incluso solo il dominio http://www.example1.com
, una richiesta CORS inviata dal dominio http://www.example2.com
riceverà l'errore 403
Forbidden
.
L'esempio seguente mostra parte di una configurazione CORS che include il dominio http://www.example1.com
nell'elemento AllowedOrigins
.
"AllowedOrigins":[
"http://www.example1.com"
]
Affinché una richiesta CORS inviata dal dominio http://www.example2.com
abbia esito positivo, il dominio http://www.example2.com
deve essere incluso nell'elemento AllowedOrigins
di configurazione CORS.
"AllowedOrigins":[
"http://www.example1.com"
"http://www.example2.com"
]
I metodi non sono consentiti
I metodi HTTP specificati in Access-Control-Request-Method
in una richiesta CORS al bucket devono corrispondere al metodo o ai metodi elencati nell'elemento AllowedMethods
della configurazione CORS. Un carattere jolly ("*"
) in AllowedMethods
corrisponderà a tutti i metodi HTTP. Per ulteriori informazioni su come aggiornare l'elemento AllowedOrigins
, consulta Configuring cross-origin resource sharing (CORS).
Nella configurazione CORS è possibile specificare i metodi seguenti nell'elemento AllowedMethods
:
-
GET
-
PUT
POST
-
DELETE
-
HEAD
L'esempio seguente mostra parte di una configurazione CORS che include il metodo GET
nell'elemento AllowedMethods
. Solo le richieste che includono il metodo GET
avranno esito positivo.
"AllowedMethods":[
"GET"
]
Se un metodo HTTP (ad esempio, PUT
) è stato utilizzato in una richiesta CORS o incluso in una richiesta di verifica CORS al bucket ma il metodo non è presente nella configurazione CORS, la richiesta genererà un errore 403 Forbidden
. Per consentire questa richiesta CORS o richiesta di verifica CORS, il metodo PUT
deve essere aggiunto alla configurazione CORS.
"AllowedMethods":[
"GET"
"PUT"
]
Le intestazione richieste non sono consentite
Le intestazioni elencate nell'intestazione Access-Control-Request-Headers
di una richiesta di verifica devono corrispondere alle intestazioni dell'elemento AllowedHeaders
nella configurazione CORS. Per un elenco di intestazioni comuni che possono essere utilizzate nelle richieste ad Amazon S3, consulta Common Request Headers. Per ulteriori informazioni su come aggiornare l'elemento AllowedHeaders
, consulta Configuring cross-origin resource sharing (CORS).
L'esempio seguente mostra parte di una configurazione CORS che include l'intestazione Authorization
nell'elemento AllowedHeaders
. Solo le richieste per l'intestazione Authorization
avranno esito positivo.
"AllowedHeaders": [
"Authorization"
]
Se un'intestazione (ad esempio, Content-MD5
) è stata inclusa in una richiesta CORS ma l'intestazione non è presente nella configurazione CORS, la richiesta genererà un errore 403 Forbidden
. Per consentire questa richiesta CORS, l'intestazione Content-MD5
deve essere aggiunta alla configurazione CORS. Se si desidera passare entrambe le intestazioni Authorization
e Content-MD5
in una richiesta CORS al bucket, verificare che entrambe le intestazioni siano incluse nell'elemento AllowedHeaders
della configurazione CORS.
"AllowedHeaders": [
"Authorization"
"Content-MD5"
]
Intestazioni non trovate nella risposta CORS
L'elemento ExposeHeaders
nella configurazione CORS identifica le intestazioni di risposta che si desidera rendere accessibili agli script e alle applicazioni in esecuzione nei browser, in risposta a una richiesta CORS.
Se gli oggetti archiviati nel bucket S3 contengono metadati definiti dall'utente (ad esempiox-amz-meta-custom-header
) oltre ai dati di risposta, questa intestazione personalizzata potrebbe contenere metadati o informazioni aggiuntivi a cui desideri accedere dal codice lato client. JavaScript Tuttavia, per impostazione predefinita, i browser bloccano l'accesso alle intestazioni personalizzate per motivi di sicurezza. Per consentire al lato client di accedere alle intestazioni personalizzate, JavaScript è necessario includere l'intestazione nella configurazione CORS.
Nell'esempio seguente, l'intestazione x-amz-meta-custom-header1
è inclusa nell'elemento ExposeHeaders
. x-amz-meta-custom-header2
non è incluso nell'elemento ExposeHeaders
e manca nella configurazione CORS. Nella risposta, verranno restituiti solo i valori inclusi nell'elementoExposeHeaders
. Se la richiesta includesse l'intestazione x-amz-meta-custom-header2
nell'intestazione Access-Control-Expose-Headers
, la risposta restituirebbe comunque 200 OK
. Tuttavia, solo l'intestazione consentita, ad esempio x-amz-meta-custom-header
, verrà restituita e mostrata nella risposta.
"ExposeHeaders": [
"x-amz-meta-custom-header1"
]
Per garantire che tutte le intestazioni vengano visualizzate nella risposta, aggiungi tutte le intestazioni consentite all'elemento ExposeHeaders
nella configurazione CORS come mostrato di seguito.
"ExposeHeaders": [
"x-amz-meta-custom-header1",
"x-amz-meta-custom-header2"
]
Considerazioni su CORS nelle integrazioni proxy S3
Se riscontrate errori e avete già controllato la configurazione CORS sul vostro bucket S3 e la richiesta multiorigine viene inviata a proxy come, provate quanto segue: AWS CloudFront
-
Configurare le impostazioni per consentire il metodo
OPTIONS
per le richieste HTTP. -
Configurare il proxy per inoltrare le seguenti intestazioni:
Origin
,Access-Control-Request-Headers
eAccess-Control-Request-Method
.
Alcuni proxy forniscono funzionalità predefinite per le richieste CORS. Ad esempio, in CloudFront, puoi configurare una politica che includa le intestazioni
che abilitano le richieste CORS (Cross-Origin Resource Sharing) quando l'origine è un bucket Amazon S3.
Questa policy ha le seguenti impostazioni:
-
Intestazioni incluse nelle richieste di origine:
Origin
Access-Control-Request-Headers
Access-Control-Request-Method
-
Cookie inclusi nelle richieste di origine: Nessuno
-
Stringhe di query incluse nelle richieste di origine: Nessuna
Per ulteriori informazioni, consulta Controllare le richieste di origine con una policy e Use managed Origin Request Policy nella CloudFront Developer Guide.