【AWS】CrossDomain解決
在AWS整合或串接資料時,
很多時候都會碰到CrossDomain的問題
這時候Console就拋出:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
諸如此類的錯誤訊息
CrossDomain 是一個跨站訪問的安全性機制
只需要在跨站的設定上好好處理,
就不太會有這些惱人的問題。
(1)AWS APIGETY 的CrossDomain
發生時機:前端用jquery訪問aws apigetway
原因:APIGetway的「Method」沒設置正確
解決方式:
官方有說明詳細原因
https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
在開發每個API的Method時,不會預先去開
當有需求的時候,再針對Method一一開啟
開啟方式按照官方文檔的流程。
需要注意的部分一樣是AllowedOrigin,
有沒有與你的發起端來源是一致。
(2)AWS S3 的CrossDomain
發生時機:前端用jquery訪問aws s3的資源檔(如json)
原因:Bucket的Permisssions沒設置正確
解決方式:
官方一樣有說明詳細原因
https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/cors.html
到Bucket的Permisssions裡找到CORS configuration
(一)確定響應標頭設定有設置
添加<ExposeHeader>ETag</ExposeHeader>
主要是因為如果沒有這個元素
JS或是一些程序進行XMLHttpRequest訪問的響應標頭就不會觸發到
(二)確定來源源有設置
確定AllowedOrigin,與你發起的來源端為匹配。
最終改為如下:
只有開啟GET,如果需要其他像POST,DELETE,再自行增加
(3)AWS Lambda output的CrossDomain
如果lambda有串接api getway做一個respon回去給ajax
則需要檢查callback是否帶有crossdomain的header
後記:
當系統架構更複雜的時候,更需要注意這些
像是之前開發時
前端使用jquery發get去訪問AWS Apigetway,
而Apigeway後續的動作是串接Aws Lmbda再去訪問 Aws Bucket
最後在Respon結果回去給前端
這時候api getway跟s3的跨站權限都需要好好檢視
否則多重問題的疊加會讓問題更難找出
像是之前開發時
前端使用jquery發get去訪問AWS Apigetway,
而Apigeway後續的動作是串接Aws Lmbda再去訪問 Aws Bucket
最後在Respon結果回去給前端
這時候api getway跟s3的跨站權限都需要好好檢視
否則多重問題的疊加會讓問題更難找出
張貼留言