I get this error when I try to connect to my websocket server:
Error during WebSocket handshake: origin mismatch: http://skerit.com != http://kipdola.be
Sure enough, I had to put in an origin response, like this:
self.client.send("Sec-WebSocket-Origin: http://kipdola.be\r\n")
self.client.send("Sec-WebSocket-Location: ws://kipdola.be:1234/\r\n")
But how do I set it to allow multiple origins?
You just echo back the origin the user provided in the request, the request looks somewhat like this:
GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: skerit.com
Origin: http://skerit.com
You perform a serverside check if the Origin header is in your list of allowed origins and just echo the origin back to the client:
self.client.send("Sec-WebSocket-Origin: " + headers["Origin"] + "\r\n")
Related
I'm trying to setup a service that already handles CORS requests and would like to keep it that way instead of handling the CORS request on the Edge Proxy.
Leaving the cors field blank didn't help at all.
Is there anyway to achieve this with Ambassador?
Ambassador will not handle CORS in anyway unless you set the cors parameter in a Mapping or Module config.
Even if that is set, the way Envoy handles CORS seems to be the behavior you are searching for.
Taking a look at the linked comment in this issue https://github.com/envoyproxy/envoy/issues/300#issuecomment-296796675, we can see how Envoy chose to implement it's CORS filter. Specifically:
Assign values to the CORS headers in the repsponse: For each of the headers specified in Table 1 above:
a. let value be the option for the header config
b. if value is not defined, continue to the next header
c. else, write the response header for the specified config option
This means that Envoy will first take the value of the headers set by the upstream service and only write them with the configured values if they are not set in the response.
You can test this by creating a route to the httpbin.org (which handles CORS) and setting cors parameter in the Mapping.
---
apiVersion: getambassador.io/v2
kind: Mapping
metadata:
name: cors-httpbin
spec:
prefix: /httpbin/
service: httpbin.org
cors:
origins:
- http://foo.example
methods:
- POST
- OPTIONS
The Mapping above should configure Envoy to set the access-control-allow-origins and access-control-allow-methods headers to http://foo.example.com and POST respectively. However, after sending a test request to this endpoint, we can see that we are instead getting very different CORS headers back in the response:
curl https://aes.example.com/httpbin/headers -v -H "Origin: http://bar.example.com" -H "Access-Control-Request-Method: GET" -X OPTIONS
* Trying 34.74.58.157:443...
* Connected to aes.example.com (10.11.12.100) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: aes.example.com
* Server certificate: Let's Encrypt Authority X3
* Server certificate: DST Root CA X3
> OPTIONS /httpbin/headers HTTP/1.1
> Host: aes.example.com
> User-Agent: curl/7.69.0
> Accept: */*
> Origin: http://bar.example.com
> Access-Control-Request-Method: GET
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< date: Thu, 19 Mar 2020 13:25:48 GMT
< content-type: text/html; charset=utf-8
< content-length: 0
< server: envoy
< allow: HEAD, OPTIONS, GET
< access-control-allow-origin: http://bar.example.com
< access-control-allow-credentials: true
< access-control-allow-methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
< access-control-max-age: 3600
< x-envoy-upstream-service-time: 33
<
* Connection #0 to host aes.example.com left intact
This is because the httpbin.org upstream is setting these headers in the response and so Envoy is defaulting to using them instead of forcing the CORS configuration we gave it. In this way, Envoy really acts as a default for CORS settings and allows upstreams to set more or less restrictive configurations as they see fit.
This behavior can be confusing and caused me a lot of headaches trying to figure it out. I hope I helped clear it up for you.
I am trying to verify an ID Token using the Firebase Admin SDK as per instructions. My current auth code looks like this (in Vue):
// Auth.vue, inside the firebaseui config callback
signInSuccessWithAuthResult: function(authResult, redirectUrl) {
authResult.user
.getIdToken(/* forceRefresh */ true)
.then(function(idToken) {
// Send token to your backend via HTTPS
// ...
console.log(idToken);
})
.catch(function(error) {
// Handle error
console.log(error);
});
The login works fine and I can get authResult perfectly. However, it seems the function getIdToken is the problem, as I get the following error on my console:
Cross-Origin Request Blocked:
The Same Origin Policy disallows reading the remote resource at
https://securetoken.googleapis.com/v1/token?key=AIzaSyApp5yu051vMJlNLoQ1ngVSd-f2k7Pdavc.
(Reason: CORS request did not succeed).
In my request list, the one hanging is an OPTIONS method, with the following headers:
OPTIONS /v1/token?key=AIzaSyApp5yu051vMJlNLoQ1ngVSd-f2k7Pdavc HTTP/1.1
Host: securetoken.googleapis.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.8,pt-BR;q=0.5,de;q=0.3
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: POST
Access-Control-Request-Headers: x-client-version
Origin: http://localhost:8080
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
I am not even sure where the problem lies. Is it coming from the Vue side? I am running it in a dev server (by simple yarn serve, vue cli 3). Would the solution be when I run Vue on a production server where I can actually configure cors?
Any light on the matter is extremely welcome...
Thanks!!
Figured it out.
I was calling it in the wrong place. What helped was this thread, which pointed me out to Preflighted Requests which is what the OPTIONS request is:
"preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.
So I realized I should not be sending this request within my Post request where I got the authorization in the first place. Moving it to another method made it work.
I'm using Gmail API Javascript, but this is problem.
Uncaught
{error: "idpiframe_initialization_failed", details: "Not a valid origin for the client: http://localhos…itelist this origin for your project's client ID."}
details
:
"Not a valid origin for the client: http://localhost has not been whitelisted for client ID 731803464357-pdq2kfb0qg5ahca5gvvht343u2qmbgdk.apps.googleusercontent.com . Please go to https://console.developers.google.com/ and whitelist this origin for your project's client ID."
error:
"idpiframe_initialization_failed"
This is my config with file: http://localhost/b.html
Did you add the Origin HTTP header before doing the HTTP request ?
const headers = new HttpHeaders().set('Origin', 'http://localhost')
i have a page that is hosted on both HTTP and HTTPS, and it makes a HTTP call with jquery to a local http server on the client computer with the following code:
var url = "http://127.0.0.1:1234/Ping";
var ajaxSettings = {
url: url,
timeout: 1000
};
return $.ajax(ajaxSettings);
the client application has the following headers:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: Accept, Origin, Content-type
This works great when using http but when using https i get a error.
Is there any way to solve this? (generating a ssl certificate and registering it seems a bit overkill)
I am trying to upload an image to a finagle (netty) server. For the OPTIONS request I return the following:
curl -X OPTIONS http://localhost:8686/images -i
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST
Browser (FireBug): http://s15.postimg.org/vtdzyfshn/Screen_Shot_2014_09_02_at_9_49_05_PM.png
The following POST request fails with
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote
resource at http://localhost:8686/images. This can be fixed by moving the resource
to the same domain or enabling CORS.
FireBug 1 (Console): http://s30.postimg.org/9utq4ridt/Screen_Shot_2014_09_02_at_9_53_41_PM.png
FireBug 2 (Net Tab): http://s16.postimg.org/jyblxfcv9/Screen_Shot_2014_09_02_at_9_54_37_PM.png
FireBug 3 (Net Tab - POST): http://s14.postimg.org/e8czua2wh/Screen_Shot_2014_09_02_at_9_54_47_PM.png
Any idea what I am missing?
(I am using this upload script: http://www.extremecss.com/creating-asynchronous-file-upload-system-using-html5-file-api/
You have to return the CORS headers (Access-Control-Allow-Origin: *) within the response header to your POST as well, instead of just within the OPTIONS response.