Да, не так давно задавал вопрос о CORS как настроить,

в итоге у меня завелась такая конструкция, кому надо пользуйтесь!
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/enable-access-log: "true"
nginx.ingress.kubernetes.io/enable-rewrite-log: "true"
nginx.ingress.kubernetes.io/proxy-body-size: 100m
ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/configuration-snippet: |-
if ($http_origin ~* (https?://.*\.site\.com)) {
set $allow_origin $http_origin;
}
more_set_headers 'Access-Control-Allow-Origin: $allow_origin';
more_set_headers 'Access-Control-Allow-Credentials: true';
more_set_headers 'Access-Control-Allow-Methods: PUT, GET, PATCH, DELETE, POST, OPTIONS';
more_set_headers 'Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
# Cors Preflight methods needs additional options and different Return Code - UPDATED
if ($request_method = 'OPTIONS') {
more_set_headers 'Access-Control-Max-Age: 1728000';
more_set_headers 'Content-Type: text/plain charset=UTF-8';
more_set_headers 'Content-Length: 0';
return 204;
}
name: ui-https-cors-ing
spec:
tls:
- hosts:
- ui.site.com
secretName: fullchain
rules:
- host: ui.site.com
http:
paths:
- path: /
backend:
serviceName: node-user-info-svc
servicePort: 8080

Ты его знаешь ?

Знаю, а что

Помоги ему напрямую

что же творят люди =). При переезде на другой контроллер ingress все перестанет работать. Почему бы это не отдать на откуп приложению, пусть само этими корсами рулит, даже балально через nginx sidecar + будет вероятность сломать сниппетами конфигурацию ingress nginx гораздо ниже

поддержу, обычно само приложение умеет правильные CORS-заголовки выставлять, многие зачем-то пытаются переопределить их на nginx-ingress-controller

а зачем кстати more_set_headers а не провославный и нативный add_header. more_set_headers он же нужен для того, чтобы несколько заголовков в одну опцию накидывать, а у вас по заголовку на одну опцию, то есть тоже самое что и при add_header. Можно просто заменить на add_header и будет тоже самое.

+++ а если не умеет, то надо пнуть прогеров чтобы научили, или sidecar c nginx втыкать. Если уж приложение требует спец. заголовки, то пусть их и выставляет само. Тащить это на балансировку L7 нет причин.

Я буду не оригинален

++++

у меня кстати была ситуация. Прилетела задача - добавить Access-Control-Allow-Origin. И прогеру прилетела задача сделать тоже самое. И мы оба сделали, я на балансировщике, он на бэкенде. В итоге получили дублирующийся Access-Control-Allow-Origin. А многие браузеры ой как такое не любят, и часть запросов сломалась. С тех пор, любые заголовки, которые требуются приложению выставляются в нем же. А на балансировщике только всякая мета информация, которая приложением не используется, или не влияет на его работоспособность.

Спасибо, в ПН на планерке пну нодеров, пусть поправят))))

Часто люди не понимают разницы между вебсервером и реверс прокси. И если у вас нджинкс работает в режиме вебсервера, то приложение не всегда получает все запросы (отдача статики шлёт привет). Поэтому иногда установку некоторых заголовков приходится выносить в вебсервер

Только аргументов собери - почему плохо так делать