API-запросы, обойдя политику безопасности CORS для разработки?
Дело в том, что наткнулся на проблему: фронт работает на порту 8080, тарантул - http.server - на 9090
Когда фронт через axios шлёт запросы http.server тарантула, то все REST API запросы в консоли тарантула отображаются как метод OPTIONS. Загуглив, понял, что это предварительный запрос на сервер, как бы спрашивая, можно ли общаться с сервером. И сервер отвечает, что нельзя. Для разрешения сервер должен отдавать в заголовке
resp.headers['Access-Control-Allow-Origin'] = '*';
Как можно разрешить проблему с CORS?) Кто-нибудь стакивался с этим?
https://learn.javascript.ru/fetch-crossorigin#cors-dlya-prostyh-zaprosov
Вопрос cors к тарантулу имеет примерно никакого отношения, это вопрос общего назначения, изучайте матчасть и настраивайте всё как вам нужно
Значит, необходимо копать в стороне фронта?
просто проставляйте этот хедер в ответах от хттп-тарантула
если можно повесить на все ответы - то очень буду благодарен примеру Если на конкретный зарос - то не сработает, ибо до него даже не доходит. Например для метода /api/route1 с методом POST не отработает функция для route1 именно POST, так как она даже не вызовется (проверял через вывод в консоль любого текста) А вот для метода /api/route1 (тот же самое) с методом OPTIONS - всё отработает. Печалька) Особенно жалко, что CORS включается даже при изменении портов. Да, безопасность, понимаю, но затык даже для localhost) Думаю, как можно решить :)
Можно. Не в тарантуле дело. Для хрома нужно указать каталог профиля в /tmp и ключ что-то вроде --disable-web-security. В Гугле есть. Поищите
Чтобы научить бекенд «правильно» (кроссбраузерно) отвечать на cross-origin запросы, нужно попотеть. Я перечислю несколько нюансов, которые всплывают в памяти. Могу ошибаться в деталях (и многое уже забыл). 1. Емнип, некоторые браузеры включают порт в same origin policy, некоторые — нет. 2. IE 11+ требует P3P policy (отдельный хедер). 3. 'Access-Control-Allow-Origin: *' работает не во всех случаях. Помню, что приходилось из запроса брать origin и подставлять его в Access-Control-Allow-Origin. Где именно не работала звездочка — не помню. Помню, что это было в контексте проблем с куками. Еще мне там понадобилось поставить 'Access-Control-Allow-Credentials: true'. 4. Не забыть научить бэкенд отвечать на OPTIONS и не забыть указать OPTIONS в Access-Control-Allow-Methods. Не забыть Access-Control-Allow-Headers, если, например, в ответах есть Content-Type или любые другие хедера не из какого-то там списка разрешенных. 5. Были какие-то приколы с Path в кукисах (уже не вспомню деталей, но что-то там с дефолтным Path не работало). Были приколы с Expires и Max-Age (в итоге ставил оба) — что-то там вокруг сессионных и персистентных кук и поддержки Expires и Max-Age в разных браузерах. 6. Меня уже занесло в сторону кук, но раз уж начал, то продолжу. Если куки могут накапливаться, то в конце концов могут упереться в лимит размера хедера (одного хедера или их общего размера) в nginx. В итоге — невозможность авторизоваться, пока не почистишь куки. И наверняка еще с десяток нюансов, про которые я уже не вспомню. Главное, смотрите, на что браузер ругается в developer tools / console, если что-то не работает. Там как правило есть подсказка, чего именно не хватает.
Спасибо большое, что помните и ответили) Для локальной разработки сделал так : для всех запросов OPTIONS заголовок отдаю в ответе разрешение на передачу данных. И всё сработало) на проде всё в докер-контейнеры заверну и по идее ошибки CORS не будет. Долго промучился, на теперь хотя бы работает. Как у меня всё устроено: 1) Разработку фронта веду на Windows 10 (ну и бэка) 2) А Tarantool-Cartridge крутится в VM Virtual Box (прокинул порты и общие папки) Привожу решение своей проблемы. Костыль, но пойдёт
https://enable-cors.org/server_nginx.html
Спасибо! Пригодится
Обсуждают сегодня