CODEWITHSUNDEEP
corscross-domaingoogle-cloud-storagegoogle-cloud-platformgsutil
James Walker
James Walker

Reputation: 403

Cloud Storage - No 'Access-Control-Allow-Origin' header is present on the requested resource for AngularJS view

According to Chrome dev tools, my requests to get my html partials have the origin header https://site-name-here.com and request header GET.
I have the following JSON file set to my bucket:

[
    {
      "origin": ["https://site-name-here.com"],
      "responseHeader": ["content-type"],
      "method": ["GET"],
      "maxAgeSeconds": 3600
    }
]

However, whenever angular tries to get the view, I get the following error: XMLHttpRequest cannot load https://storage.googleapis.com/bucket-name/view-path.html?. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://site-name-here.com' is therefore not allowed access.

I am also serving javascript and css files from Cloud Storage, but they're working fine, I assume because CSS doesn't have CORS restrictions and I'm using $sceDelegateProvider.resourceUrlWhitelist() in Angular for the scripts?

Edit: Working now, I'm assuming something was cached and it was serving me an old version.

Upvotes: 16

Views: 17508

Answers (8)

Nazar Kotsyuba
Nazar Kotsyuba

Reputation: 177

If you have request + preflight you might need to set additional parameters.

"responseHeader": ["Content-Type", "Origin", "Accept","Authorization","Content-Length", "X-Requested-With"],

enter image description here

enter image description here

https://mockoon.com/docs/latest/cors/

Full CORS configuration:

[
    {
      "origin": ["*"],
      "method": ["GET", "POST", "DELETE", "PUT", "HEAD"],
      "responseHeader": ["Content-Type", "Origin", "Accept","Authorization","Content-Length", "X-Requested-With"],
      "maxAgeSeconds": 3600
    }
]

Upvotes: 0

Harvey
Harvey

Reputation: 71

The problem might not be from the CORS configuration but from other errors being masked by CORS error.

To rule out problems with your configuration, check the CORS configuration of your bucket with this command - gsutil cors get gs://BUCKET_NAME. If your configuration is visible, then it's definitely not a configuration issue.

On the other hand, CORS might be masking other 4xx or 5xx errors returned by Cloud storage. This is because errors returned by Cloud storage do not have the access control headers set.

To see the real 4xx and 5xx errors on your browser, Try to disable the CORS check. A lot of plugins can assist with disabling CORS on Chrome.

Upvotes: 1

mohammed shahid saddapalli
mohammed shahid saddapalli

Reputation: 1

This is working for me. I used gsutil to set this CORS policy for my GCP storage bucket .Remove the cache of angular web application before you give it a try after setting the cors policy for more info see here.

[
    {
      "origin": ["https://site-name-here.com"],
      "responseHeader": "Content-Type",
      "method": ["GET"],
      "maxAgeSeconds": 3600
    }
]

Upvotes: 0

taka_i_no
taka_i_no

Reputation: 1

If cache is the problem, try this.

gsutil setmeta -h "Cache-Control:no-cache" gs://BUCKET_NAME/OBJECT_NAME

Viewing and editing object metadata

Cache may remain somewhere in the network for a while.

Upvotes: 0

Kar Keng Chan
Kar Keng Chan

Reputation: 171

Just to support @Idcmp's answer, the CORS policy does take a while before taking full effect (this is not documented tho). I've spent ~2 hours trying to figure out why I'm still getting CORS error in browser even though I use the below policy (which is highly NOT recommended, but it's fine for my personal testing project).

{
    "cors": [
      {
        "origin": [
          "*"
        ],
        "method": [
          "*"
        ],
        "responseHeader": [
          "*"
        ],
        "maxAgeSeconds": 3600
      }
    ]
}

ps Take a coffee break after applying a new CORS policy, you definitely deserve it

Upvotes: 17

Idcmp
Idcmp

Reputation: 691

As a summary for people who find this question via Google, applying a CORS policy seems to take a bit of time before it takes effect. Answers above indicate it could be due to intermediate caches, etc -- things that are likely out of your immediate control.

If you can, apply a CORS policy (via gsutil) that allows a wildcard origin and test your request either via https://www.test-cors.org/ or curl --verbose --output /dev/null -H "Origin: https://your.actual.origin.here" https://storage.googleapis.com/bucket/object you will eventually see headers you're looking for:

< access-control-allow-origin: *
< access-control-expose-headers: Content-Length, Date, Server, Transfer-Encoding, X-GUploader-UploadID, X-Google-Trace

Once it works, restrict the origins and methods you're actually using so you don't wind up on the news and/or have a surprisingly large bandwidth bill.

If you've done this and are still having issues, try uploading an object with a new name to the bucket (that is 100% not cached anywhere) to test.

Upvotes: 5

jcroll
jcroll

Reputation: 7155

The following got it working for me:

[
    {
      "origin": ["https://site-name-here.com"],
      "responseHeader": "*",
      "method": ["GET"],
      "maxAgeSeconds": 3600
    }
]

Upvotes: 1

Alex
Alex

Reputation: 315

In fact, this type of issue can potentially be resolved upon clearing the browser or other intermediary service’s cache.

In case your application is running on a Google App Engine instance, it is possible to clear its intermediate cache by redeploying a new version of the app. Alternatively, it may be also possible to set a default_expiration or simple expiration of files cached within web proxies and browsers (see this Static cache expiration section of the app.yaml reference for more information).

Upvotes: 3

Related Questions