Can anyone provide any insight into how CORS works on Rackspace Cloud Files?
I tried setting the value of "Access-Control-Allow-Origin" to the url of my webserver but I can still access the public url of the object by just pasting it into a browser.
Maybe I misunderstand how CORS works? Setting the access control allow origin to my web server would only allow the file to be accessed from the web server. Me, as a user pasting the url into the web browser, would be from a different origin, no ?
The documentation at Rackspace isn't the best sometimes for stuff like this (or I'm looking in the wrong place...)
That's not really what CORS is for. Cross-origin resource sharing (CORS) is a mechanism that allows Javascript on a web page to make XMLHttpRequests to another domain, not the domain the Javascript originated from, see CORS.
It has nothing to do with making an object or container public/private.
On Rackspace, CORS works according to this doc.
Related
Posts to my Azure Web App are being replied to with additional Http Header information, specifically the following:
Access-Control-Expose-Headers: Request-Context
Set-Cookie: ARRAffinity=xxx;Path=/;HttpOnly;Domain=ws.caxxx
Request-Context: appId=cid-v1:xxx
This appears to be due to Custom Domains configured on my site, i.e., the Azure site url is xxx.azurewebsites.net and I have a Custom Domain set ws.xxx.com. I say that because when I'm posting to the Azure url I do not see the Access-Control-Expose-Headers and the Request-Context lines in the headers.
I do not have CORS configured for this site, so I don't know why I am getting the Access-Control-Expose-Headers.
Note that this is the Production site. I have another Testing site where I do not have this problem! So there must be something with my Azure configuration.
On my Testing site, I can remove the ARRAffinity cookie by adding the httpProtocol clause to the web.config. However, when added to the Production site it throws a 500 error.
The posting devices are IoT devices, so I need to reduce the headers sent back to the devices.
Any advice is greatly appreciated!
I am trying to make a website cross origin isolated, and enabled the following headers on my site:
https://web.dev/cross-origin-isolation-guide/
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Firebase auth uses a call to:
https://<AUTH_DOMAIN>/__/auth/iframe?apiKey=<API_KEY>&appName=[DEFAULT]
This gets blocked if you and makes authentication fail.
Because your site has the Cross-Origin Embedder Policy (COEP) enabled, each resource must specify a suitable Cross-Origin Resource Policy (CORP). This behavior prevents a document from loading cross-origin resources which don’t explicitly grant permission to be loaded.
To solve this, add the following to the resource’s response header:
Cross-Origin-Resource-Policy: same-site if the resource and your site are served from the same site.
Cross-Origin-Resource-Policy: cross-origin if the resource is served from another location than your website. ⚠️If you set this header, any website can embed this resource.
How does one fix this? It seems like the root issue is that firebase needs to set a header on their side ?
I am using HLS streaming with the Amazon S3 and Cloud Front using the JWplayer.(With Rails)
I used the Signed URL to encrypt the URL and created an Origin Access Identity as given in the Amazon Cloud Front documentation.
The Signed URL's are generated fine.
I also have a 'crossdomain.xml' file in my bucket which is allowing all the origins(I have given '*')
Now, when I am trying to play my Hls video files from my bucket, I am getting crossdomain access denied issue
I think JW Player is trying to access the 'crossdomain.xml' file without the signed hash. So, it's getting that error.
I have tested my file in demo JWplayer Stream tester and this is the error I am getting in console.
Fetch API cannot load http://xxxxxxxx.cloudfront.net/xxx/1/1m_test.ts.
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://demo.jwplayer.com' is therefore not allowed access.
The response had HTTP status code 403.
If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Here is the ScreenShot.
Please help me out. Thank You.
This is the link I followed to configure my CloudFront Distribution
I just had the same problem (but with the Flowplayer). I am not sure yet about security risks (and if all steps are needed), but I got it running with:
adding permissions on the crossdomain.xml for everyone to open/download
adding a behaviour in the cloudfront distribution only for crossdomain.xml without restricting access (above the behaviour for * with restricted access)
and then I noticed that in the bucket, the link to the crossdomain.xml was something like "https://some-server.amazonaws.com/bucket.name/%1Fcrossdomain.xml" (notice the weird %1F) and that when I went on rename of the crossdomain.xml, I could delete one invisible character on first position of the name (I didn't make the crossdomain.xml, so I am not sure how this happened)
Edit:
I had hlsjs also running with this and making the crossdomain.xml accessible somehow disabled the CORS request. I am still looking into this.
I have a site, which uses where2GetIt API. I need to get some data from this site,
but after making request, I get "No 'Access-Control-Allow-Origin' header is present on the
requested resource. Origin 'null' is therefore not allowed access" error.
I assume, that the problem is, that I have not access to API. How can I get the access to API?
If you're doing this with Javascript, make sure you understand CORS
...CORS gives web servers cross-domain access controls, which enable
secure cross-domain data transfers. Modern browsers use CORS in an API
container - such as XMLHttpRequest - to mitigate risks of cross-origin
HTTP requests.
See also this StackOverflow question How does Access-Control-Allow-Origin header work?
I'm having a doozy of a time trying to serve static HTML templates from Amazon CloudFront.
I can perform a jQuery.get on Firefox for my HTML hosted on S3 just fine. The same thing for CloudFront returns an OPTIONS 403 Forbidden. And I can't perform an ajax get for either S3 or CloudFront files on Chrome. I assume that Angular is having the same problem.
I don't know how it fetches remote templates, but it's returning the same error as a jQuery.get. My CORS config is fine according to Amazon tech support and as I said I can get the files directly from S3 on Firefox so it works in one case.
My question is, how do I get it working in all browsers and with CloudFront and with an Angular templateUrl?
For people coming from google, a bit more
Turns out Amazon actually does support CORS via SSL when the CORS settings are on an S3 bucket. The bad part comes in when cloudfront caches the headers for the CORS response. If you're fetching from an origin that could be mixed http & https you'll run into the case where the allowed origin from CloudFront will say http but you want https. That of course causes the browser to blow up. To make matters worse, CloudFront will cache slightly differing versions if you accept compressed content. Thus if you try to debug this with curl, you'll think all is well then find it isn't in the browser (try passing --compressed to curl).
One, admittedly frustrating, solution is just ditch the entire CloudFront thing and serve directly from the S3 bucket.
It looks like Amazon does not currently support SSL and CORS on CloudFront or S3, which is the crux of the problem. Other CDNs like Limelight or Akamai allow you to add your SSL cert to a CNAME which circumvents the problem, but Amazon does not allow that either and other CDNs are cost prohibitive. The best alternative seems to be serving the html from your own server on your domain. Here is a solution for Angular and Rails: https://stackoverflow.com/a/12180837/256066