I would like to use amp-list on a website that is otherwise valid AMP to avoid using an amp-iframe embed with JS. I just finished reading the cors docs by Google AMP at https://www.ampproject.org/docs/fundamentals/amp-cors-requests and am still confused - is it possible to have the json source for the amp-list from a remote domain?
The thing I need is to have a source of URLs+titles generated and updated outside of the main jekyll website because the main website takes too long to build.
I am testing it with a valid JSON and headers as follows and am getting nothing in console and the list is not rendered, so I presume what I am trying to do is not possible?
/source.json
Content-type: application/json; charset=utf-8
X-Frame-Options: ALLOW
Access-Control-Allow-Headers: Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://fakename.netlify.com/
AMP-Access-Control-Allow-Source-Origin: https://fakename.netlify.com/
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Expose-Headers: AMP-Access-Control-Allow-Source-Origin
Related
General:
Request URL:x/site.php
Request Method:OPTIONS
Status Code:302 Found
Remote Address:x.x.x.x:80
Response Headers:
view source
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Origin:*
Access-Control-Max-Age:300
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Length:0
Content-Type:text/html; charset=UTF-8
Date:Thu, 02 Mar 2017 14:27:21 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Location:y
Pragma:no-cache
Server:Apache/2.4.25 (Ubuntu)
Request Headers:
view source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:authorization
Access-Control-Request-Method:POST
Cache-Control:no-cache
Connection:keep-alive
DNT:1
Host:x
Origin:http://127.0.0.1:3000
Pragma:no-cache
Referer:http://127.0.0.1:3000/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.90 Safari/537.36
Apache virtualhost config looks as so:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://127.0.0.1:3000"
Header set Access-Control-Allow-Origin "http://127.0.0.1"
Header set Access-Control-Max-Age "300"
Header set Access-Control-Allow-Credentials "true"
Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept"
Header set Access-Control-Allow-Methods "POST, GET, PUT, DELETE, PATCH, OPTIONS"
</IfModule>
The preflight request is skipping the apache config and hitting my webapp directly, which does a redirect (hence the 302 and the location: y).
I don't know why the preflight request is not being handled by apache?
To fully CORS-enable an Apache web server, you need to have it configured to look like this:
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Headers "Authorization"
Header always set Access-Control-Allow-Methods "GET"
Header always set Access-Control-Expose-Headers "Content-Security-Policy, Location"
Header always set Access-Control-Max-Age "600"
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
Longer explanation at https://benjaminhorn.io/code/setting-cors-cross-origin-resource-sharing-on-apache-with-correct-response-headers-allowing-everything-through/
Some general notes on what values to set for the various Access-Control- response headers:
Access-Control-Allow-Headers: you must set it to include any header names your request sends except CORS-safelisted header names or so-called “forbidden” header names (names of headers set by the browser that you can’t set in your JavaScript); the spec alternatively allows the * wildcard as its value—so you can try it, though some browsers may not support it yet: Chrome bug, Firefox bug, Safari bug.
Access-Control-Allow-Methods: the spec alternatively allows the * wildcard—but again, as with Access-Control-Allow-Headers: *, some browsers may not support it yet.
Access-Control-Expose-Headers: set to include any response headers beyond Expires, Cache-Control, Content-Type, Pragma, Last-Modified, and Content-Language that your frontend code needs to read. A lot of people forget to set this and end up baffled about why they can’t read the value of a particular response header). Again the spec alternatively allows the * wildcard here, but some browsers may not support it yet.
Access-Control-Max-Age: Chrome has an upper limit of 600 (10 minutes) hardcoded, so there’s no point in setting a higher value for it than that (Chrome will just throttle it down to 10 minutes if you set it higher, and Safari limits it to only 5 minutes).
So then, about the particular request shown in the question, the specific changes and additions that would need to made are these:
Use Header always set instead of just Header set.
Use mod_rewrite to handle the OPTIONS by just sending back 200 OK with those headers.
The request has Access-Control-Request-Headers:authorization so in the Apache config, add Authorization in the Access-Control-Allow-Headers response header too.
Origin is a “forbidden” header name set by the browser, and Accept is a CORS-safelisted header name, so no need to include them in Access-Control-Allow-Headers.
The request sends no Content-Type, so no need for it in Access-Control-Allow-Headers in the response (and never needed for GET requests and otherwise only needed if the type is not application/x-www-form-urlencoded, text/plain, or multipart/form-data).
For Access-Control-Allow-Methods, the request seems to just be a GET, so unless the plan’s to also make POST/PUT/DELETE/PATCH requests, no point in including them.
I'm trying to access an API via VB6.
I'm successfully able to "POST" AND "GET".
Now running into problems with "PUT"
I'm able to "PUT" using Postman but cannot get it to work in my VB6 Code (able to "GET" and "POST" though)
If i do a
objWinHttp.GetAllResponseHeaders
I get:
**Allow: OPTIONS, GET, POST, HEAD**
Content-Length: 2
Content-Type: application/json
Server: cloudflare
Set-Cookie: __cfduid=dade65e860f9164a08757164f49c2c6ce1524753607; expires=Fri, + 26-Apr-19 14:40:07 GMT; path=/; domain=.monday.com; HttpOnly; Secure
Status: 405 Method Not Allowed
Strict-Transport-Security: max-age=31536000
X-Rack-Cache: invalidate, pass
X-Request-Id: 55aba84b06aaaf03f1e4127ddf9a603a
X-Runtime: 0.009866
X-UA-Compatible: IE=Edge,chrome=1
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
CF-RAY: 4119cd7c1f1571d9-ORD
I'be tried modifying the Header "Allow" by using
ObjWinHttp.SetRequestHeader "Allow", "GET, POST, OPTIONS, PUT, DELETE"
and
objWinHttp.setRequestHeader "Access-Control-Allow-Methods", "GET, POST, OPTIONS, PUT, DELETE"
to no luck
Any ideas as to why I can't allow PUT requests or another reason this won't work.
You can't demand that the server change itself by trying to send a response header as a request header. The server may not be able to process a PUT method at all anyway rather than simply disallowing them.
For a normal simple-minded page-serving web server a PUT is an attempt to replace a static page, server-side script, or other resource. Why would they ever allow just anybody to hack them like that?
I have an AWS S3 bucket with the following CORS policy:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
<ExposeHeader>Access-Control-Allow-Origin</ExposeHeader>
</CORSRule>
</CORSConfiguration>
In my app, I load a page of images from the bucket. The images appear on the page as expected. When I click on one of the images to open it in the Adobe Creative SDK, the SDK fails to load the image because it is blocked by CORS. The SDK takes the url of the image and loads it via AJAX. The SDK has an option to enable CORS and appears to be sending the proper Origin header (See screenshot), however AWS is not including the Access-Control-Allow-Origin-Header, causing the image to be blocked by CORS.
I've scoured every question on here about this subject and it seems like no one has a straight answer. There are dozens of questions on this subject that are unanswered, however in many of those cases it appears that the AJAX request isn't sending the Origin header or that the bucket isn't properly configured. In this case, neither of those are true, which is why this is not a duplicate.
As you can see in the screenshot, the request includes the Origin header, but the response does not include the Access-Control-Allow-Origin header. What I would like to know is:
1. Why isn't S3 sending the proper header if my bucket is properly configured?
2. Is it possible that when the Adobe Creative SDK requests the image via AJAX, the browser sees that the image is already cached and tried to serve the cached image (which doesn't have the Origin header) instead?
3. If #2 is the case, how can I forcibly add the Origin header to the image request? In the app, the image is the background of a div (css background-image property).
I created a test bucket, enabled CORS, and used your CORS rules.
Note that I am not convinced that <ExposeHeader>Access-Control-Allow-Origin</ExposeHeader> is necessary, but it should not do any harm by being present, so I've retained it.
The behavior I observe in testing is not consistent with what you are showing in your browser's request/response headers.
Using curl, I set the Origin: header to http://example.com. (Yes, that's actually what I set it to... this was not modified in the output below).
$ curl -v http://xxxxxxxxxxxx.s3.amazonaws.com/index.txt -H 'Origin: http://example.com'
* Hostname was NOT found in DNS cache
* Trying 54.231.98.120...
* Connected to xxxxxxxxxxxx.s3.amazonaws.com (54.231.98.120) port 80 (#0)
> GET /index.txt HTTP/1.1
> User-Agent: curl/7.35.0
> Host: xxxxxxxxxxxx
> Accept: */*
> Origin: http://example.com
>
< HTTP/1.1 200 OK
< x-amz-id-2: pF39K26ii42SzxSU2Dt0KT2z7+xmfyiP4yekp9s4DCYJo0jlRwCTDg6QO6f0HMIL4H9b640zq7U=
< x-amz-request-id: 3B18A563CFF4E485
< Date: Sat, 28 May 2016 21:49:21 GMT
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET
< Access-Control-Expose-Headers: Access-Control-Allow-Origin
< Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
< Cache-Control: no-cache
< Last-Modified: Sat, 28 May 2016 21:40:57 GMT
< ETag: "cd21a8c7268dc6af728d180f9a3a81d7"
< Accept-Ranges: bytes
< Content-Type: text/plain
< Content-Length: 71
* Server AmazonS3 is not blacklisted
< Server: AmazonS3
Why is this interesting?
S3, with CORS configured and a <CORSRule> matching your request, always returns the CORS response headers and a Vary: header (which means "If you vary one of the following headers in your request, I may vary something about my response.") The headers from the above output that I am referring to, specifically, are these.
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Expose-Headers: Access-Control-Allow-Origin
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
There is only one exception I can find to this, which is when there is not a matching CORS rule. To demonstrate that, I first changed my CORS configuration to <AllowedOrigin>http://example.com</AllowedOrigin> and then repeated the request. Note that the response is almost identical, except that S3 uses the exact origin in the response, and adds Access-Control-Allow-Credentials.
< Access-Control-Allow-Origin: http://example.com
< Access-Control-Allow-Methods: GET
< Access-Control-Expose-Headers: Access-Control-Allow-Origin
< Access-Control-Allow-Credentials: true
< Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
...however, if I -- still using the more restrictive CORS rule that specifies a specific origin -- then send a request for Origin: example.org, which is an origin that is not mentioned in my CORS configuration and has no wildcard <AllowedOrigin> to match, S3 responds as though CORS was not configured at all.
< HTTP/1.1 200 OK
< x-amz-id-2: WJ0QmIZ6jTQYefFi8GjlDQkZKFHDX8/5cmejeulhG1ov3/NdoSXbsTKetYpxvXPML8aUnPNZ/ac=
< x-amz-request-id: 15A03D8B1E08A830
< Date: Sat, 28 May 2016 21:58:34 GMT
< Cache-Control: no-cache
...etc.
This takes me back to my initial conclusion that the request you've shown your browser making does not match the timing of when you configured the bucket for CORS, and may have been cached before your bucket's CORS settings were in the correct state, or before they matched those you've posted in the question.
If an Origin: header was present on that request, as the browser shows that it was, then S3 should have added the CORS response headers, whether or not the request was actually a cross-origin request.
Your next steps would be to try this with a new object at a new path that there is no possibility of being cached, or try the common browser cache-busting tactic of adding ?some-random=thing-here to the object's URL when making the request. Failing that, you should consider proving or disproving correct behavior by your bucket using a tool like curl that shows exactly what's happening in the request/response.
As I know that if cors request comes with some extra headers set, first server needs to process it.
With CORS, the server must send the Access-Control-Allow-Headers header to allow uncommon request headers from the client.
Access-Control-Allow-Headers ... - Comma-delimited list of the supported request headers.
e.g suppose my pre-flight request is
OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
Then from server-side I will send response
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
My question is -
should I close the connection on server side while we send pre-flight response to client?
One more thing how can I cached pre-flight request for all other distinct subsequent requests?
Thanks
You could cache the OPTIONS request using the
Access-Control-Max-Age
header.
Attach it to the headers collection of the OPTIONS response.
But nevertheless an initial OPTIONS request by the user agent (browser) has to be made, you cannot avoid this.
But all further OPTIONS requests are cached and not issued to the server.
No need to close the connection.
Access-Control-Allow-Origin: http://hello-world.example
Access-Control-Max-Age: 3628800
Access-Control-Allow-Methods: PUT
as explained here, search for
could have the following headers specified
to get to the designated text section.
I followed all the instructions and 'troubleshooting' guide for CORS but I have a feeling it's just not working.. i've spent the last 2 days just trying to list a bucket contents and not matter how i configure my CORS for my bucket it fails same way.
What I'm using:
An angularJS client app talking directly to Google Cloud Storage using JSON API from my local machine (i.e. localhost)
Followed all the advice here:
https://developers.google.com/storage/docs/cross-origin
My Bucket:
gs://okrp-dev
THE ERROR (chrome latest browser)
XMLHttpRequest cannot load https://storage.googleapis.com/storage/v1beta2/b/okrp-dev/o. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.
My CORS file now (though i've tried every other permutation):
bash-3.2$ gsutil cors get gs://okrp-dev
<?xml version="1.0" ?>
<CorsConfig>
<Cors>
<Origins>
<Origin>*</Origin>
<Origin>
http://localhost</Origin>
</Origins>
<Methods>
<Method>GET</Method>
<Method>POST</Method>
<Method>HEAD</Method>
</Methods>
<ResponseHeaders>
<ResponseHeader>*</ResponseHeader>
</ResponseHeaders>
<MaxAgeSec>86400</MaxAgeSec>
</Cors>
</CorsConfig>
Trace from Chrome dev tools Network tab:
Remote Address:74.125.193.132:443
Request URL:https://storage.googleapis.com/storage/v1beta2/b/okrp-dev/o
Request Method:OPTIONS
Status Code:200 OK
Request Headers
:host:
storage.googleapis.com
:method:OPTIONS
:path: /storage/v1beta2/b/okrp-dev/o
:scheme:https
:version:
HTTP/1.1
accept:*/*
accept-encoding:
gzip,deflate,sdch
accept-language:en-US,en;q=0.8,tr;q=0.6
access-control-request-headers:access-control-allow-origin, accept, authentication
access-control-request-method:GET
cache-control:
no-cache
origin:
http://localhost
pragma:
no-cache
referer:http://localhost/okrp/app/
Response Headersview source
alternate-protocol:443:quic
cache-control:
private, max-age=0
content-length:0
content-type:
text/html; charset=UTF-8
server:HTTP Upload Server Built on Mar 5 2014 15:51:04 (1394063464)
status:200 OK
version:
HTTP/1.1
NOTE I have the authentication working fine. I'm no longer getting a 401. Only 404.
NOTE I also of course totally opened up all permission on the bucket and object and that does not help at all.
How else can I troubleshoot this??