Разрешение восходящему потоку обрабатывать запросы cors - PullRequest
Новая
       121

Разрешение восходящему потоку обрабатывать запросы cors

0 голосов
/ 19 марта 2020

Я пытаюсь настроить сервис, который уже обрабатывает запросы CORS и хотел бы сохранить его таким образом, вместо того чтобы обрабатывать запрос CORS на Edge Proxy.

Оставив поле cors пустым, не делали ' не помогает вообще.

Есть ли способ добиться этого с послом?

1 Ответ

1 голос
/ 19 марта 2020

Посол не будет обрабатывать CORS в любом случае, если вы не установите параметр cors в конфигурации Mapping или Module.

Даже если он установлен, то, как Envoy обрабатывает CORS, похоже, поведение, которое вы ищете.

Взглянув на связанный комментарий в этом выпуске https://github.com/envoyproxy/envoy/issues/300#issuecomment -296796675 , мы увидим, как Envoy решил реализовать свой фильтр CORS. В частности:

Присвойте значения заголовкам CORS в ответе: Для каждого из заголовков, указанных в таблице 1 выше:

a. пусть значение будет параметром для конфигурации заголовка

b. если значение не определено, переходите к следующему заголовку

c. в противном случае, напишите заголовок ответа для указанной опции конфигурации

Это означает, что Envoy сначала примет значение заголовков, установленных восходящей службой, и запишет их только с настроенным значения, если они не установлены в ответе.

Вы можете проверить это, создав маршрут к httpbin.org (который обрабатывает CORS) и установив параметр cors в 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

Mapping выше следует настроить Envoy для установки заголовков access-control-allow-origins и access-control-allow-methods на http://foo.example.com и POST соответственно. Однако после отправки тестового запроса в эту конечную точку мы видим, что вместо этого мы получаем очень разные заголовки CORS в ответе: 

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

Это происходит потому, что httpbin.org upstream устанавливает эти заголовки в ответ и поэтому посланник по умолчанию использует их вместо форсированной конфигурации CORS, которую мы дали. Таким образом, Envoy действительно действует по умолчанию для настроек CORS и позволяет восходящим потокам устанавливать более или менее ограничивающие конфигурации по своему усмотрению.

Такое поведение может сбивать с толку и вызывать у меня множество головных болей, пытаясь понять это. вне. Я надеюсь, что помог вам разобраться с этим.

...