🏆 Рейтинг ІТ-работодателей 2019: уже собрано более 5000 анкет. Оцените свою компанию!
×Закрыть

Почему Backend девы плохо знают CORS?

Доброго времени суток!

Ситуация для меня настолько непонятна, что решился создать тему.

Я — FE dev, и кажется ещё не было ни одного проекта, на котором Backend изначально нормально бы настроил CORS. Большинство не настраивают его вообще, пока я не наткнусь на это, сделав первую попытку запроса к API.

Более того, когда при отправке запроса я получаю ошибку на pre-flight request и пишу коллегам, что надо бы пофиксить, часто выясняется, что они не в курсе, что браузеры автоматом отправляют OPTIONS запросы, что вообще это за запросы и вообще «зачем ты отправляешь OPTIONS».

Собственно вопрос: как так получается, что вроде бы опытные бэкенд специалисты не в курсе базовых вещей? Почему я — фронт — знаю об этом больше, чем они, хотя это как раз их часть работы?

Заранее спасибо за адекватные ответы.

LinkedIn

Лучшие комментарии пропустить

Сначала я думал, что это у топик-стартера зазнайства многовато. Но потом почитал комменты от «бекэндеров» и натурально офигел от уровня чванства, необоснованной спеси и недалекого высокомерия.

«бекэндеры ваще не должны знать как вы там апишечку дергаете», «тебе нужно, ты и заведи тикет с описанием всех нужных хэдеров», «это ваши фронтэнд заморочки, бекэнду на них плевать», «это вы, фронтэндеры, там че-то потрындели, а нас ваще не касается, мы тут на митинге спим» — ладно, если бы это какие-то залетные вайтишники писали — может человек с завода пришел где все друг на друга ответственность спихивать привыкли, ладно бы писал зелёный джун, но видеть подобные телеги от целого «чиф софтвэа инжинира» как минимум странно.

Славаяйцам, с такими токсичными людьми в командах сталкиваться еще не доводилось, и, надеюсь, не доведется.

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

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

В большинстве случаев бекенд не торчит наружу в интернет, а спрятан за reverse proxy. Это может быть nginx, aws elb, traefik и тп. И CORS и прочие штуки (например gzip) настраиваются там.

это как раз их часть работы

Не совсем. CORS — это браузерная специфика и это в первую очередь ответственность фронта понимать как работает браузер и быть способным сформулировать внятные требования к апи в том числе на уровне хедеров.

1 — Потому что бэкэндер вообще может не знать каким способом вы дергаете сервер.
2 — Часть сервера которая отдает ответ килиенту, это отдельный слой — верхушка айсберга. Дальше идут BAL, DAL и это еще простой случай.
3 — Часто основаная масса бэкэндера работы уходит на бизнесс логику BAL, работу с данными DAL и прочее, чем сложнее проект тем больше там работы и тем меньше вспоминают про левел которые отдает UI-ке данные.
4 — Это как раз таки твоя работа — определить вменяемые требования со стороны клиента.

Почему я — фронт — знаю об этом больше, чем они, хотя это как раз их часть работы?

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

Я — FE dev, и кажется ещё не было ни одного проекта, на котором Backend изначально нормально бы настроил CORS.

Для начала опиши, что такое «нормально настроить CORS». Желательно со ссылкой на спецификацию, стандарт или соглашение с перечислением упомянутых тобой норм. Ты ведь не сам их придумал? Если «нормальная настройка» существует в реальности, то я охотно отвечу тебе на заданный тобой вопрос.

пишу коллегам, что надо бы пофиксить, часто выясняется, что они не в курсе, что браузеры автоматом отправляют OPTIONS запросы

Далее опиши, что про специфику запросов написано в документации по API, которые бекэндеры тебе предоставили. Нет ли там предписаний использовать POST или GET? Если есть, то ты говоришь «пофиксить» там, где по сути речь идет о «реализовать новую фичу» — девелоперы очень не любят такие тикеты вне зависимости от того, бэк они или фронт.
Предположим, что ты таки поставил бэкам тикет на реализацию, ты ведь написал там конкретные детали того, что просишь реализовать, не так ли? Или ты там написал «реализуйте всё возможное многообразие options-запросов и cors-фич потому что это нормально»? Конечно же нет, ты написал тикет с заявкой на реализацию конкретно того сценария, который понадобился тебе для работы. Тогда не понятно, почему возник твой пост на доу, ведь бэкам осталось сделать несложный кусочек работы. Возможно, у бэков есть какие-то приоритеты и планы, а твоя заявка на реализацию нового функционала не имеет значительной бизнес-ценности, поэтому получает приоритет ниже, чем тебе хотелось бы. Но это уже догадки. Как бы там ни было, а проблема не в бэке и не в браузере, а в твоем понимании «нормальности». Поэтому для ответа на твой вопрос подождем ссылку на «нормальную настройку».

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Сталкивался с таким. Это потому что чистый бекендер не пишет фронт. Создаешь эндпоинт, тестишь его постманом, отчитываешься что фича готова. А так как учатся большинство сами (даже при наличии CS-образования), то и не знают пока кто-то не скажет.

В-принципе, если на том конце не тормоза, которые любую проблему обсуждают полгода, то это легко решается. Для бэкэнда на фреймворках для ноды достаточно найти и установить модуль cors, и это покроет 99% случаев.

---

А вообще, бесит этот CORS. Недавно хотел отключить API чтобы на любые запросы отвечало 500м кодом с текстом о технических работах, в формате жсон (чтобы когда фронт шлет запрос, пользователь видел эту информацию). Настроил nginx, в браузере ошибка не отображается, в curl всё отлично. Долго мучался пока в консоли не заметил ошибки CORS и не дошло что содержимое ответа недоступно из-за отсутствия нужного заголовка (allow-origin-чего-то-там-такое).

А зачем это всё? Говорят для защиты от XSS. Но так у меня изменение данных только через POST/PATCH, авторизация JWT, пользовательский контент проходит обработку перед выводом на экран. Не знаю как для этого можно XSS-атаку организовать.

Создать левый сайт и с него дергать твое АПИ.
Решается проверкой заголовка Host, но это ж нужно по всему вебу включать

Но зачем? В моем случае там нет открытых данных совсем, разве что писать альтернативный клиент. А за такое можно и спасибо сказать.

Так-то я понимаю что это нужно, бесить меньше не перестает. Особенно когда в дев тулзах смотришь на запрос и на вкладке response видишь что-то вроде «unable to load response» без объяснений. Но это вопрос реализации хромом конечно.

Но зачем?

Ну украсть данные пользователя, например.

Опишите схему такой атаки

Я ж вот эту вот часть зря писал

Но так у меня изменение данных только через POST/PATCH, авторизация JWT, пользовательский контент проходит обработку перед выводом на экран

Нет кук никаких. Для любого запроса к закрытым данным нужно передать в заголовках токен. И как мне кажется, в разных современных туториалах по аутентификации в SPA промоутят именно такой способ. Я думал есть какая-то новая схема атаки, которая это обходит.

А корс есть, и его все равно приходится настраивать, ради высшей цели

Не у всех нет кук. Скорее, наоборот, много у кого они есть.

Копируешь дизайн оригинального сайта, логинишься через АПИ (не сработает при логине через SSO server).

Куда копируешь? В чем цель?

Я думал есть какая-то новая схема атаки, которая это обходит.

Это ты вопрос задавал.

Схема стара как мир. Создаешь фейковый домен, типа my.cool.aplication.com (вместо my.cool.application.com), который копирует оригинальный сайт.

Отсылаешь пользователю ссылку, он там логинится (если повезет), воруешь данные, profit.

И при чем здесь корс и чем он поможет?

Корс не дасть послати запит на сервер навіть за наявності кредентіалс які користувач надасть в фейковій формі. Хоча це можна обійти через сервер проксі.

А зачем его посылать? Чтобы украсть пароль, нужно его послать на свой сервер, а не на мой. И ты сам же ответил что это можно обойти через прокси.

Корс предназначен для одной единственной цели — защита от XSS-атак для сайтов, использующих куки для аутентификации. Больше ни для чего. Ни от фишинга, ни от альтернативных клиентов он не защищает.

А зачем его посылать?

І дійсно, лишні дії))

Корс предназначен для одной единственной цели — защита от XSS-атак

Абсолютно

Ты точно программист? CORS не даст послать запрос с не разрешённого явно домена.

Ты точно программист?

Можешь подойти к зеркалу и задать ему этот вопрос 🙂

Так навіщо отримувати з серверу через клієнта JWT токен, якщо можна просто пароль засейвити, і потім вже зі свого серверу слати авторизацію(чи аутентифікацію, я постійно плутаю їх) на сервер фб і отримати цей токен. А з серверу жоден корс не спасе.

Можно и так.
Но может быть двухфакторная авторизация, может быть привязка токена к устройству или айпишнику.

То, что вы описываете не имеет отношение к CORS, то вы описываете обычный фишинг.
Смысл CORS в следующем — допустим вы залогинились на фейсбук, и поставили галочку запомнить вас на этом компьютере. Фейсбук сохраняет куку в вашем браузере, которая при обращение к фейсбуку браузером добавляется в запрос и через нее поднимается сессия вашего пользователя. Когда такой запрос идет со страницы c домена facebook.com — то нет проблем, потому что это страница самого фейсбука.

Но вот пользователь заходит на страницу siskipiski.com, на которой злостный хакер разместил кусок джакаскрипта, который создает XMLHttpRequest (XHR) запрос к фейсбуку. И если бы не полиси браузера, который запрещает это делать без разрешения сервера, то злостный хакер уже залогинен в ваш фейсбук кукой из браузера и рассылает всем вашим друзьям спам об увеличении органов.

Поэтому если фейсбук хочет, чтобы у его комьюнити были большие органы, он должен при ответе сервера посылать дополнительный хеддер, где скажет — разрещаю siskipiski.com посылать ко мне XHR запросы. Ну или вообще сгорел сарай гори и хата — танцуют все — AllowedHost *

то злостный хакер уже залогинен в ваш фейсбук кукой из браузера

Тільки не хакер, а жертва хакера)

Спасибо, я это знаю.

Изначально я отвечал на вопрос о возможной схеме атаки, если используется jwt аутентификация и не было бы CORS.

Просто там CORS не настроен).

Буду краток: Именно фронт решает, чего ему надобно. Бэкенд может при этом быть вообще хрен знает где, за хрен знает каким количеством звеньев, на то он и бэк. И самих бэкендов на один фронт будет чёртова дюжина, и совсем не факт что они собственные.

Грубо говоря, жопа не должна знать об унитазе. Голова должна.

CORS это вообще не знание, это ПОЛИТИКА. И да, по дефолту настройки у софта не позволяют раздавать всё всем, что есть разумно. Если ты считаешь что это неправильно, значит не работал ни с индусами, ни с русскими веб-макаками.

То есть сам CORS прописывать — это уровень копипасты готовых решений, читай уровень сисадмина. Но разработчик в целом продукта должен знать, ЧТО он разрешает отдавать, и КОМУ он это разрешает отдавать. По дефолту, разумеется, только своему домену.

PS. Страшнее всего с позиции соблюдения CORS разумеется ослик IE, как бы эту ослятину не переназывали. Даже тот факт, что эту ослиную шкуру натянули на Хромиум, не значит что ишак перестал быковать. По крайней мере года 3 назад проблемы были, потом просто не сталкивался, вероятно починили. Но факт остаётся фактом — тесты на CORS нужно пускать в том числе на IE.

PPS. На «локалхосте» тестировать — себя не уважать. В любом случае нужно даже на локальном компе прописать домен. Именно для того, чтобы понимать, когда очередной джун попытался срезать углы и захардкодить адрес. Или же когда сам в тестах его захардкодил, чтобы побыстреньку протестить, и забыл выбросить тест из общей последовательности.

ТС прочитав як настроювати на nodejs CORS і вважає, що це не знання, а священний грааль, який треба донести до публіки доу.

если кому то надо было больше обоснований почему фронты в среднем макаки — этот тред бесценен.

почему фронты в среднем макаки

И тем не менее в зоопарке «гориллам» неплохо так платят djinni.co/q/cbac7456 ;)

Да нет, макака же как раз бэк-дев, который знает что апи будет дергаться из браузера, но не знает про CORS.

Почему я — фронт — знаю об этом больше, чем они, хотя это как раз их часть работы?

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

Я — FE dev, и кажется ещё не было ни одного проекта, на котором Backend изначально нормально бы настроил CORS.

Для начала опиши, что такое «нормально настроить CORS». Желательно со ссылкой на спецификацию, стандарт или соглашение с перечислением упомянутых тобой норм. Ты ведь не сам их придумал? Если «нормальная настройка» существует в реальности, то я охотно отвечу тебе на заданный тобой вопрос.

пишу коллегам, что надо бы пофиксить, часто выясняется, что они не в курсе, что браузеры автоматом отправляют OPTIONS запросы

Далее опиши, что про специфику запросов написано в документации по API, которые бекэндеры тебе предоставили. Нет ли там предписаний использовать POST или GET? Если есть, то ты говоришь «пофиксить» там, где по сути речь идет о «реализовать новую фичу» — девелоперы очень не любят такие тикеты вне зависимости от того, бэк они или фронт.
Предположим, что ты таки поставил бэкам тикет на реализацию, ты ведь написал там конкретные детали того, что просишь реализовать, не так ли? Или ты там написал «реализуйте всё возможное многообразие options-запросов и cors-фич потому что это нормально»? Конечно же нет, ты написал тикет с заявкой на реализацию конкретно того сценария, который понадобился тебе для работы. Тогда не понятно, почему возник твой пост на доу, ведь бэкам осталось сделать несложный кусочек работы. Возможно, у бэков есть какие-то приоритеты и планы, а твоя заявка на реализацию нового функционала не имеет значительной бизнес-ценности, поэтому получает приоритет ниже, чем тебе хотелось бы. Но это уже догадки. Как бы там ни было, а проблема не в бэке и не в браузере, а в твоем понимании «нормальности». Поэтому для ответа на твой вопрос подождем ссылку на «нормальную настройку».

Что-то мне подсказывает, что для автора в итоге «нормальной» настройкой окажется что-то типа
'allowedOrigins' => ['*'], 'allowedHeaders' => ['*'], 'allowedMethods' => ['*']
Так, чтоб уже наверняка)

да, обычно со стековерфлоу сразу в конфиг прода такое копипастят джуны и мегасиньоры, а потом удивляешься, почему всякое говно прод долбить начинает

Это, я буду долбить курлом или ботом и мне пофигу что там у вас в заголовках. Я не браузер, чтобы придерживаться CORS

Нет ли там предписаний использовать POST или GET? Если есть, то ты говоришь «пофиксить» там, где по сути речь идет о «реализовать новую фичу» — девелоперы очень не любят такие тикеты вне зависимости от того, бэк они или фронт.

Эм, шта? Если пишешь апишку, которую будет дергать жс-клиент из браузера, то без OPTIONS апишка будет нерабочей. Фронтендер не выбирает отправлять эти запросы или нет. Бразуер видит разные домены (даже, курва, поддомены) и включает CORS. И всё. Я бы рад был на уровне клиента приказать браузеру его отключить, но это фича безопасности

Если пишешь апишку, которую будет дергать жс-клиент из браузера

Если поступил заказ на апишку, которую [описание клиентов, задачи, ограничений и требований], то да. Если же поступил заказ на апишку «ну вы ж там три года назад что-то делали, а теперь оно у меня из браузера не дергается, вы не знаете базовых вещей, фиксьте баг и дальше делайте нормально», то ситуация совсем другая. Мы сейчас находимся в реальном мире или в мире вольных предположений?

Еще раз — ждем от топикстартера описание «нормально настроенного CORS», которое подойдет к любому API и потому должно быть реализовано бекэндером заранее, до появления клиента. Топикстартер просил адекватности — так вот это она и есть.

Еще раз — ждем от топикстартера описание «нормально настроенного CORS», которое подойдет к любому API

Заголовки со звездочками и «всё можно» — подойдет к любому апи (не совсем безопасно, конечно)

Топикстартер просил адекватности — так вот это она и есть

Адекватность — это когда тебя просят написать апи, но ты помнишь про корс и спрашиваешь, как апи будет использоваться, с каких доменов, пытаешься понять нужна ли защита вообще и подготавливаешь строчки в конфиге с удобными на данный момент дефолтными значениями. В документации (или хотя бы ридми) указываешь что вот бывает корс и настроить его можно в таком-то файлике или такой-то переменной окружения.

Никто конечно так не делает, ведь в моде сделать побыстрее и чтоб от*бались

автор, понимаешь в чем дело
тут если спросить, далеко не все синиоры понимают что такое TCP/IP, а ты про кокой-то корс, нафиг он кому упал это же документацию знать надо

Вот чтобы не слушать этот бред с двух сторон, почти всегда я работал Full Stack.

Как пример на одном проекте, iOS разработчик вонял из-за того, что DateTime в json присылался то с миллисекундами когда они есть, то без когда они равны 0. Его абсолютно не волновало, что с точки зрения стандарта ISO, это нормальное поведение. Но он вместо нормального парсера, использовал видать какую-то самописный загрузчик по шаблону. Одно дело по просить, мало ли костылей всяких, но тут было другое — «Это Ваш косяк!!». Криков было столько, что легче было массово обрезать эти миллисекунды, чем с ним разбираться.

обычно таких надо посылать на*** с ссылкой на стандарт, если воняет дальше пойти к его менеджеру и на конкретном примере обсудить его не компетентность и поговорить что может надо бы поискать альтернативу либо дать его в подчинение кому-то более адекватному

Конфликтный человек, не любящий решать проблемы. Ну или выгорел нахер уже.

Гм... Відповідь досить проста. Бекенд цього не робе бо це дуже швидко може призвести до tight coupling між сервісами та ускладнити роботу девопсів.
Наприклад, мій сервіс може навть не знати яке в нього буде доменне ім’я, а ви вимагаєте щоб він знав, з яких піддоменів ви завантажили UI і виконуєте запити...
Максимум, що вам можуть пообіцяти — це реалізувати JSONP, якщо ви хочете викликати якісь JS функції.

Ну мы не знаем конечно в какого размера проектах работает ТС. Очень возможно что всё там бэкэнды знают. Тысячя микросервисов — это 1% проектов.

Ну и я сам работал на маленьком проекте где бэкэнд не был в курсе за CORS, хотя прекрасно было известно что запросы будут из браузера, поэтому верю

Мода на разделенный фронтенд и бекенд появилась не так уж и давно. Кто-то успел узнать, что надо добавить пару строчек в nginx, кому-то это еще предстоит, а кто-то никогда этого не узнает, потому что всю жизнь будет работать с монолитами или имеет в команде девопса.

ну худой случай е сть CORS-прокси для фронтенда на вашей же горячо любимой ноде, если апи или бэк недонастроен

браузеры автоматом отправляют OPTIONS запросы

ну не автоматом, а если домены разные

нагуглил — прочитал про CORS — забыл. в чем проблема?
зачем этот мусор в голове держать?

Потому что развелось слишком много «20-летних сеньоров», для которых разработка бэкэнда — это натащить пакетов из npm/nuget, а как и почему оно работает оно там работает — черт его знает. Некоторые «сеньоры» не разбираются не то что в CORS — они даже не в курсе что, например, обращение к данным через Entity Framework генерирует некий SQL запрос.

Недавно просматривал объявления на апворке. Так вот, в вебе эра синьоров прошла и настала эра экспертов. Ищут реакт экспертов, вордпресс экспертов, шопифай экспертов. В 90% объявлений в заголовке будет эксперт (правда бюджеты как-то не экспертные)

Скоро будут искать гуру и ниндзей.

Просмотрел тред, основную идею уже высказал — настоящее бекенд апи обычно скрыто за апачами/нжинксами и балансировщиками, и настраивать CORS это их зона ответственности.

А я еще наброшу. Далеко не все апи пишутся чтобы отдать в браузер жсончик. Многие пишутся не для браузерных клиентов, внезапно, а для machine-to-machine коммуникации, где этот ваш корс нафиг ваще не упал.

Это всё хорошо, но если убрать из заголовка бэкэнд, вопрос остается. Почему человек, в зоне ответственности которого находится предоставить фронтенду апи, не знает про корс?

Ну так это приведет к смене смысла всего треда вообщет.
Это вопрос совсем к другому человеку.

То ж треба щоб одразу у всіх так підгоріло від якоїсь дрібниці. Схаменіться! Ви нагріваєте планету!

Просто это был пятничный топик)

тс: врывается с шашкой наголо в самую гущу бекендеров
бекендеры: указывают гусару на его место в круговороте жизни
soy boyz: токсичность! настоящий мужчина кхм бекендер должен! атятя!

Если бэк забыл про корс или не в курсе как будет использоваться апи (хотя, а как же коммуникабельность и спросить?), это одно. Если не знал про корс — то как бы не в его правах указывать «гусару» на его место.

Во-первых, как уже ниже говорили, между бэкендом и фронтендом чаще всего не один слой других серверов. Если ваш фронт обращается напрямую к бэкенд серверу — это вот вообще не очень. Именно эти промежуточные уровни должны разбираться в CORS, гзипах, лоадбалансерах итд. И именно это, чаще всего, бэкенду как раз совсем не интересно.

Во-вторых, исходя коментов ТСа ниже, конкретная проблема заключается в том, что он со своего локалхоста не может достучаться до апи-сервера. Если я это правильно понял, то тогда перед пинанием бэков за непонимание CORS, ему бы стоило попробовать прописать в хостс файле 127.0.0.1 mycoolapp.domain.com и забыть про эту ситуацию.

Не, hosts не поможет, как я понял, у него или API на удаленном сервере или локально, но под другим портом.

В этой ситуации важно лишь то, чтобы и фронт и апи сервились с одного домена. Поэтому, если у него апи отвечает на api.domain.com, то записи front.domain.com в хостс более, чем достаточно. Если его и апи, и фронт, развернуты локально, то и разницы в доменах нет, соотв. и необходимости в корс.

Часто статику и API локально хостят под localhost на разных портах, а в проде на domain.com и domain.com/api. В этих случаях hosts не помошник.

Если серсисы хостятся локально под разными портами — проблема CORS. Если статика локально на localhost, а API на стейдже/проде — тоже CORS и ни тот ни другой кейс не лечится доменом в hosts.

При чем тут порты к корс ?) Порты — чисто проблема проксирования. Оба локально == на одном домене по определению. Корс — проблема разных доменов.

Мы ведь только что решили, что порты решаются за счет проксирования, не ?) proxy.conf.json у ангулара, уверен, что у других фреймоворков есть аналоги.

Не, мы про hosts без proxy. По крайней мере я так понял твой изначальный пост.

За счёт проксирования вообще решается все по корс локально.

Конечно может, и не только может, но и должно. Единственная проблема, которая остается — ориджин домен. Который и решается за счет хостс файла либо записи в другом днс. Но, используя Ваши же слова, что все это может значить для фронтенда, если есть бэкенд, который «должен вотэтовотвсе», в т.ч. настроить локальное место разработчика-фронта?)

За счёт проксирования решается и ориджин домен и без записи в хостс — в любом случае, на фронте базовый урл для апи должен конфигурироваться.

Для локальной разработки проблем нет, как раз.

Этот мануал получше.
developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Тут и про порты:
„A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, or port) from its own.”
И про то, нафига это бекендщикам
„Who should read this article?
Everyone, really.
More specifically, this article is for web administrators, server developers, and front-end developers.”
Можно ещё и вот это читнуть раз тема зашла
developer.mozilla.org/...​erver-Side_Access_Control

Что может значит мнение какой-то мозиллы для программиста, если он Бекэндер

Этот мануал получше.

Этот мануал есть в ответе, ссылку на который я привел 🙂.

Тут еще вопрос, кто такие server developers.
Я бы это интерпретировал, как ребята, которые пишут nginx или django — то есть, сервера.

Кстати, я не уверен, что оно из-коробки будет и для api.domain.com и front.domain.com работать. Скорее всего на API нужно будет добавить что-то типа *.domain.com.

Поэтому, если у него апи отвечает на api.domain.com, то записи front.domain.com в хостс более, чем достаточно

Ага, щас. Субдомены тоже под корсом 😐

Це ви про «The Corrs» нє? ;)))

Д — делегирование.

вообще мне кажется проблема в не правильном определение фронтенда — которое заполонило все и вся

нынче фронтенд трактуется как все что в браузере, хотя с моей точки зрения можно выделить фронтенд сервер часть, что туда может входить:
— реверс прокси/конфигурация CSP/gzip и куча другого на уровне хттп протокола
— собиралка фронт логов
— всякие юзер преференсес

И даже рендеринг HTML, если он происходит на сервере.

Ну обычно какой-то сср вполне себе кейс

ето че, в формате png шлете? ...или это новомодная перевиралка терминов, типа весь джс на серваке?

Хз чем занимается программер во фрилансе, из профиля непонятно. Но есть серверные технологии, которые позволяют на сервере геренить HTML. Может слышали, ASP.NET, PHP, Ruby? Сюда же можно отнести и server-side rendering всяких Vue.js, React, Angular. Гугл в помощь, в общем. Никто в здравом уме это в png не конвертит 😉.

Когда я посл. раз трогал хтмл именно так и было, только так. А теперь, значит, уже не так, но ето «не так» не пошло, и вернулись к старому с новым названием? Норм ход.
Вообще это «генерация» или по русски — создание ...а рендер — ето уже в браузере визуалка.

Хз, что там сейчас и как рендерят, я фронт уже пару лет не трогал.
Бывает так, что слова пишутся одинаково, но имеют разное значение — омонимы называтюся.

рендеринг это новое название?
хз по моему это всегда было и всякие темплейт движки в конце ф-цию с именем render и вызывали чтобы выплюнуть хтмл.

Так бывает делается — фронт сервер + апишка. Часто фронт сервер пишут на ноде и туда лазят фронтэндеры и лепят там все что нужно для работы с клиентом, это все их стэк и технологии. Вообще довольно не плохой кейс. Фронтэндеры не морочат голову бэкендерам и добавляют все сами, что им нужно на своем сервере. От бэкендеров нужна только апишка которая отдает данные в json.
Работал так и мне нравится такой подход. Но такое дороже обходится :-) Как минимум от фронтэндера нужно требовать знания еще и по серверной части. + доп на девопс отдельного инстанса. Но это больше от проекта зависит.

Ну я считаю это единственно правильным разделом на бекенд фронтенд но обычно против него как фронтендеры так и бекендеры а потом конфликты как у тс

Да по разному, было и когда монолит был, а фронт вещами занимался один бэкэндер которому нравилось возиться с фронтом, она там все приводил в порядок, остальные туда особо не лезли, или консультировались с ним и/или отдавали на ревью где он поправлял что и как надо сделать. Все было изи.
И никаких срачей на форуме. Все были довольны.

Ну собственно это тоже решение только с другой стороны — надо знать свой контекст + соседние и тогда все норм. По факту тот же случай когда бекендщик не знает как ось реализует многопоточность, или как работает индекс в бд, фронт который не знает хттп и как днс работает, собственно как браузер внутри работает

но обычно против него как фронтендеры так и бекендеры

Почему против ?

Бекендеры боятся что в их сервер лезут, фронты потому что лень учиться проще сказать что это бекенд

Бекендеры боятся что в их сервер лезут

Так какраз жеш не лезут, ибо апликейшены разделены ж.

фронты потому что лень учиться проще сказать что это бекенд

Ну по бизнес логике — всегда можно сказать что бакэнд.

Я тебе говорю что я слышал, согласен что это полный дебилизм

Это все фигня, а вот только представьте как с таким Дартаньяном в одной команде работать будет=)

после одной-двух дружественных бесед у подобных кавалеристов происходит охлаждение траханья

Двічі за мою професійну кар’єру мені доводилося щось фіксати/додавати для того щоб оте CORS працювало. Абревіатуру пам’ятаю, що воно якось там пов’язано з хідерами, OPTIONS, чимось таким теж пам’ятаю, а от що воно саме таке і для чого — ні, не пам’ятаю. І не збираюся навіть. Бо як тут вже пояснили погуглити і пофіксати це 5 хвилин, щоб зрозуміти чому воно взагалі потрібно — ще 5 хвилин. Але ніякого відношення до функціоналу, фіч, бізнес-логіки все це не має. Тому нащо його запам’ятовувати?

І є велечезна купа речей які я пам’ятаю лише умовно: операції та команди openssl, ключі gcc/llvm, як помирити keychain на Mac з AD і ще сотні і сотні іншого подібного.

Ну вообще, если не создаешь новое апи с нуля каждый день, то корс в голове держать сложно, да

    Backend девы -это женщины разрабатывающие серверную часть приложения?

Женщины разрабатывающие бэк. Свой или чужой, там уж от проекта зависит. В случае топика, походу разработали фронтэндовский бэк, полыхает знатно :-)

я прямо вижу заголовок: женщина разрабатывает свой бек HD

Разработчица заднего конца пришла к разработчику переднего конца, чтобы он помог ей соединить передний конец с задним. Tags: мастурбация, анал, 69, страпон

    сразу видно шё вы на этом тоже уже обожглись...

это женщины анальницы

Нах это знать бекенд разрабам ? Это должны знать браузерные программисты ака фронтендеры. Тем более в этих свистельно-пердельных технологиях каждый день шото меняется.

Сначала я думал, что это у топик-стартера зазнайства многовато. Но потом почитал комменты от «бекэндеров» и натурально офигел от уровня чванства, необоснованной спеси и недалекого высокомерия.

«бекэндеры ваще не должны знать как вы там апишечку дергаете», «тебе нужно, ты и заведи тикет с описанием всех нужных хэдеров», «это ваши фронтэнд заморочки, бекэнду на них плевать», «это вы, фронтэндеры, там че-то потрындели, а нас ваще не касается, мы тут на митинге спим» — ладно, если бы это какие-то залетные вайтишники писали — может человек с завода пришел где все друг на друга ответственность спихивать привыкли, ладно бы писал зелёный джун, но видеть подобные телеги от целого «чиф софтвэа инжинира» как минимум странно.

Славаяйцам, с такими токсичными людьми в командах сталкиваться еще не доводилось, и, надеюсь, не доведется.

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

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

Некоторые это называют «здоровой атмосферой в коллективе» лол

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

Славаяйцам, с такими токсичными людьми в командах сталкиваться еще не доводилось, и, надеюсь, не доведется.

Врятли встретите. Человек коментящий в доу, и реальный человек — разные вещи.

Про teamwork слышали далеко не все люди

От тут є суть суперечки. Стара класика, але рукописи не горять. Діалог двох програмістів, клієнт вс сервер :) SoftServe, затертий рік...
tinyurl.com/y6cadz8z

Проблема в том, что одни чуваки запилили класс с полем, а другие чуваки не могут забиндить его к GridView, потому что GridView не может биндиться к полям, а только к свойствам?

Тебе ж сказали на аспнети всьо идеально бля пздц! От воопще идеально!

Він три сутки не чекінив — не хуінив, а ти...

Backend изначально нормально бы настроил CORS.

Это не стоит на повестке дня сразу, потому и не думают.

В спрингбуте корс включаеться простым копированием мвц конфигурации со стек-оверфлоу в течении 5 минут. Ну 20 минут почитать, если гребец не знает что такое корс (бывает). Проблема слегка преувеличена.

я вот тоже не знаю что такое CORS (на собеседовании не спрашивали да и требований знать это у нас нет). для спринг бутового приложения откуда-то скопипастил конфиг

а доступ до бекендових сорців є ?
ідеш включаеш сам і все, дєлов то
зачем єта драма ?

Если по делу — чёт у вас там в «датском королевстве» прогнило с взаимодействием внутри команды.
Если не по делу — если обобщатт на том же уровне: фронтэндеры ваще ничего не знают и их постоянно приходится учить что такое REST :)

Прочитал CQRS на всякий случай ужаснулся

Я первый раз тоже прочитал как SQRS )))

Ты имел ввиду SPQR

Паттерны — временны, слава римской империи — вечна.

Радуйтесь что уже не надо объяснять что такое JSONP, и почему бекендерам надо уродовать свой красивый json на выходе :) Все эти нюансы это ограничения браузера, браузер- всего лишь один из клиентов, потому фронт и должен по беспокоится, чтобы бекендеры запили необходимые ему заголовки.

Вообще, это часть намного большей проблемы, когда бекендеры вообще не хотят вникать в проблемы и трудности пользователей своего АПИ.

Я уже, блин, стал мастером спорта по объяснению что такое CORS, зачем он нужен, почему это не баг фронтенда, почему это надо включать на АПИ сервере, почему нужен сертификат.

Сталкиваюсь со странным непониманием и нежеланием вообще вникать в эту тему.

Также, научился включать CORS в AWS API Gateway, Ngnix, asp.net core, Express.
Научился обходить CORS, включая реверс прокси в ngnix.

Сталкиваюсь со странным непониманием и нежеланием вообще вникать в эту тему.

ничего странного. легче позвать специалиста, который стал мастером спорта по CORS в AWS API Gateway, Ngnix, asp.net core, Express.
чем тратить время на вникание в спеку, для того что тебе понадобится... раз в год хотя бы?

А тем более вникать в то, что вообще тебе не понадобится.

Полностью одобряю такой подход как увеличивающий мою ценность на рынке труда. И новые технологии тоже не нужно изучать, через сколько они понадобятся, через год? А может и вообще не понадобятся.

большинству бекендеров CORS не понадобится смотреть и через год. и через два.
большинству команд компетенция по CORS не нужна, достаточно привлечь стороннего эксперта.

Полно узкоспециализированных технологий.
Спецов по ним мало не потому что эти технологии сложные (хотя бывает что и поэтому), а потому что потребность в таких специалистах крайне низкая.

Уже написали

Прочитал CORS на всякий случай ужаснулся

аналогично, настраивая у себя, потому что фронтендеры ничего не могли объяснить — почитал, понял что нафик не нужно копать тему — для проекта не нужно,
нашел обсуждения настроек для используемого фреймворка и, скопипастил, подправил — и забыл уже, что там да как.
конфиг просто будет кочевать между проектами, да и все.

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

Прочитал CORS на всякий случай ужаснулся

Он там CQRS вместо CORS прочёл

Там проблема на 5 мин гугления и еще 5 мин на фикс. Можно подумать это вообще кто-то запоминать будет. Закомитал и забыл, пусть гугел помнит.

А пятиминутный фикс — это что, звездочки?

Звездочки страшны не всегда, на самом деле. И на этапе разработки мвп вполне подойдут. Потом можно поправить конфиг.

Это уже тема следующего топика 😉

Самое сложное — объяснить это все бекендерам. Сама настройка на 2 минуты.

Теперь стало ясно почему в Украине многие не любят микросервисы — это ж для каждого нужно корс настраивать, а шо оно таке вообще?

а причём cors к микросервисам, когда server-to-server взаимодействия и никакого броузера?

server-to-server конечно тоже есть, но если у тебя весь фронт одним монолитом, то это уже не микросервисы.

Былобы любопытно посмотреть на фронт который не одним монолитом, когда вокруг все на спа помешаны. Как там, корс, сессиии решаються и еще многочего. Главное — бизнес кейс.

Есть такая штука как frontend microservices, если интересует с головой посмотри opencomponents. А так допустим в реакте любой компонент может рендерится как аппликуха своя

Ну вот в моем текущем проекте так и есть. Каждая фича это связка фронт микросервиса, который имеет свой бек микросервис. Фронт на ангуляре.

Монолит фронт к микросервисам ничего общего не имеет. Фронтенд в таких случаях обособленное приложение которое обычно имеет свой сервер (тоже монолит) и через него общается с микросервисами. Если с твоими микросервисами общается монолит это не делает их монолитом

Мікросервіси, вони для веб-браузера ?

Це мабуть про випадок коли хочеться API вручну смикати через якийсь swagger чи щось подібне.

Мне кажется? Или 4-5 лет назад не было так популярно делать фронтенд на одном домене, а бэкенд на другом. Фронт отдавался тем же сервером, но например по путям /static и /public, а API отвечало по /api путям.
Сейчас стали разделять на разные домены, а фронт и бэк лежат в разных репозиториях. А когда-то давно я помню мы с верстальщиками в одном репозитории работали. Какой тогда CORS?

пути не имеют значения — главное чтобы совпадали хост, порт и протокол

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

Судя по ответам в топике, так и есть.

Судя по ответам половина даже не слышала об этом. «Шо нам там на бекенде нужно знать ещё?»

Собрал всё нужное за реверс прокси, можно даже на один домен замапить и никаких корс.

Так это ещё дополнительно за трафик и CPU на проксе платить придётся ))))

Ну, на неё ж накидываются ещё обязанности, как на API gateway (не ради ж одного CORS’а делают), поэтому вопросом трафика можно пренебречь — она бы и так была. А если теоретически только ради CORS’а, то можно втулить всё (проксю и сервисы) на один инстанс в виде контейнеров).

Так она красной нитью по всему топику проходит. Если разрешать доступ к API с любого хоста, данные пользователя могут быть украдены запросами с другого сайта.

Опишите схему атаки 🙂

Особливо сайту, у якого його ангулярство і бекенд на одному домені-вебсервері, і де ніколи corsa не було, а тепер побіжуть і допишуть зірочки.

Браузерная специфика не входит в область ответственности бакэндера. Наша работа заканчивается на джсоне с данными.

Но спрашивать будут с бекендера (ну или девопса, если он есть).

Интересно, а как ты хотешь получить адекватный ответ на скандальное заявление?...

може так (епічно):
і вистроїлась черга з девопсів і бєкедщиків довжиною з кілометр на доу, всі на поклон до ТС , без шапок, за корс каятись і кланятись

Потому что они сфокусированы на более других вещах. Возможно что знают, но забыли.

Сразу вспомнил забавный момент, как меня спросили на собесе, что это такое, я сказал — не помню (хотя в голове было, что я с ним что-то делал), а на следующий день вспомнил, и что это, и зачем оно надо — как-то пришлось для корректной работы Swagger UI его настраивать, но это всё пролетело так быстро, что уже и успел забыть... поэтому сорян).

Залежить від компанії і проекту по різному все це організовується і як вже нижче писали люди без проблем можуть довго працювати і не стикатись з цим

На попередній роботі багато різних апішок було, іноді інтеграції з стороніми сервісами, майже всі деви знали і без проблеми могли налаштувати, там же пізніше для деяких проектів все перейшло в nginx, щоб менше паритись

На теперішній роботі вся ця фігня схована десь хз де в налаштуваннях сервера і деви не мають туди доступів навіть, іноді летить і чекаємо поки девопси пофіксіть

А взагалі для локалхоста, щоб не паритись простіше додати одну стрічку в вебпак конфіг і не паритись і когось не напрягати

Дякую за адекватну відповідь

Почему Backend девы плохо знают CORS?

бэкенд девы — девушки из подтанцовки штоле ?
Корс (канадское пиво) почему плохо знают ? рекламы мало наверно или не угощает никто ?
вообщем да, согласен, это проблема, угощайте снеснительных девушек из подтанцовки пивом парни ...
всем хороших выходных

Короткий огляд треду:
Фронтендер: «Бекенд під..си, а я Д’Артаньян».
Бекенд, 2 штуки: «Ну буває, це тому що...».
Бекенд, 10 штук: «Сам такий».

Д`Артаньяном себя не считаю (реально хотел узнать, что я упускаю в ситуации), но коммент позабавил))

У тебя просто отсутствует понимание того, чем мы вообще занимаемся. Зато апломба выше крыши.

Бекенд, 10 штук: «Сам такий».

Категоричные заявления всегда вызывают у людей такую реакцию

В ASP.NET Core CORS включается одной строчкой в Startup.cs. Не надо даже писать какие-то отдельные обработчики для OPTIONS — всё за тебя делает пайплайн обработки запросов. Иногда эту строчку просто забывают вставить.

В ноде это тоже одна-две строчки. Я понимаю ситуации когда забывают добавить.

Но когда на просьбу добавить нужный заголовок для CORS начинают дискуссию вроде «А зачем оно тебе надо? Ты что-то неправильно делаешь» вместо того чтобы загуглить что это за зверь такой (раз человек не в курсе) и просто сделать... тут я немного в смятении оказываюсь.

Надо не дискуссию, а блокер в жиру

А где асп.нет поставит в Access-Control-Allow-Origin звёздочку, а где — имя хоста? (В веб вообще ни в зуб ногой, просто интересно.)

По-умолчанию ничего не ставится, это все разработчик включает.

Настроил бы Reverse Proxy, чтобы все запросы шли на один хост, сэкономил бы и себе и коллегам кучу времени.

UPD: Вижу, ниже уже ответили.

а кто будет за трафик и CPU на проксе платить? )))

надо менять или изменять команду и способы коммуникации

Тому що до апішок всі робили html сторінки і там таких проблем не було.
Як же давно це було

В большинстве случаев бекенд не торчит наружу в интернет, а спрятан за reverse proxy. Это может быть nginx, aws elb, traefik и тп. И CORS и прочие штуки (например gzip) настраиваются там.

да, но как бы надо понимать как наиболее популярный http клиенты работают

Понимание есть, reverse proxy у фронтендера нет.

Это решается наличием docker-compose.yml в проекте.

Как одна из опций. У меня простостенький nginx крутится в контейнере без docker-compose. Если k8s — там с этим еще проще (наверное).

браузеры автоматом отправляют OPTIONS запросы

Потому что им это нафиг не упало? Я, например, о КОРСе только сейчас вот узнал, до этого как-то спокойно жил, не тужил.

Почему я — фронт — знаю об этом больше, чем они

Почему тогда не перекатишься в бэк и не сделаешь хорошо фронтам?

до этого как-то спокойно жил, не тужил

А что за проекты у вас?

Почему тогда не перекатишься в бэк и не сделаешь хорошо фронтам?

Планирую в фулстак поначалу, в процессе перекатывания.

Разные фулстаковские, хоть и с уклоном во фронт. В основном — внутриорганизационные, хотя пользователи раскиданы по всему миру. Прежде, чем добраться до бэка — запрос должен продраться сквозь reverse proxy с лоадбалансерами.

Планирую в фулстак поначалу, в процессе перекатывания.

Не лезь туда, оно тебя сожрет.

Ибо это встречается ой как не часто?
С моих реалий — за последние 3 года браузер напрямую к прод бэку ходил ровно 0 раз

В данном случае это не особо важно, тут больше подходит вопрос о сложности и величине проекта, чем он больше — тем глубже лежит бэк, до него может быть несколько слоев сервисов, прокси и прочего добра.. При этом конфиги лежат где-то глубоко в кубере и правятся раз в пару месяцев специально обучеными для этого людьми.
А типы, да вот пару навскидку — финансы, геймдев, обработка чего-либо, мобилки, другие платформы.

На мой взгляд важно, так как на мой взгляд большинство отписывается с точки зрения больших сложных проектов. Но в мире дохрена простых «формочек» и «crudов» простых и прямолинейных. И куча девов, которые их годами делает.

так они скорее всего и знают об этом, ибо сталкивались и не раз) Когда-то и у меня были темплейты для корса на разных языках, но сейчас даже репа с ними удалена.
У вас же вопрос «почему они не слышали об этом», вот и ответы такие, ибо люди не сталкивались и не видели, и не факт, что когда-то пригодится

так они скорее всего и знают об этом

в том то и дело, что нет)))

Плюсую. Часто наблюдаю ситуацию когда человек очень удивляется «незнанию элементарных вещей», что забавно ведь то что это элементарно для тебя != элементарно по определению.
Более чем уверен, что любой из тех бэкэндеров знает много «элементарных» вещей про которые автор даже не слышал.
П.С.: столкнулся с CORS впервые когда писал свой пет проект, на работе за 2+ лет как-то не доводилось повстречать :)

Базовым я его назвал потому что
— для настройки под веб это необходимо
— потому что открыл несколько курсов по ноде, там об этом в самой базовой главе пишется

Так что да, мне это показалось базовым.

на работе за 2+ лет как-то не доводилось повстречать

Вы за 2 года для веба не делали апи?

Делал новые, фиксил старые и но CORS это не коснулось :)
Здесь много ситуаций расписали в комментах почему люди могут не сталкиваться с таким работая по многу лет.

1 — Потому что бэкэндер вообще может не знать каким способом вы дергаете сервер.
2 — Часть сервера которая отдает ответ килиенту, это отдельный слой — верхушка айсберга. Дальше идут BAL, DAL и это еще простой случай.
3 — Часто основаная масса бэкэндера работы уходит на бизнесс логику BAL, работу с данными DAL и прочее, чем сложнее проект тем больше там работы и тем меньше вспоминают про левел которые отдает UI-ке данные.
4 — Это как раз таки твоя работа — определить вменяемые требования со стороны клиента.

Потому что бэкэндер вообще может не знать каким способом вы дергаете сервер

Способом, описанным в документации апишки, которую создал бэкенд дев?

У тебя подгорает или что?
Тебе нужны хедеры? Заведи тикет с дескрипшеном и жди пока пофиксят.
Откуда бэкндщик знает что тебе нужно другие домены дергать?

Какие другие домены?

Начинаем разработку веб-приложения. Фронт на локалхосте, к примеру. Бэк в документации предоставляет способы общения с сервером. Посылаешь запрос, получаешь ошибку на pre-flight запрос.

Какие другие домены?

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain.

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

З локалхосту браузер теж блокує запит. Треба додавати його на сервері. У мене так зроблено:

app.UseCors(builder => builder.WithOrigins("frontenddomain.com„, „http://localhost:3000”, "https://localhost:3000").AllowAnyMethod().AllowAnyHeader().AllowCredentials());

Я хз вообще что за префалай запрос

С этого бы начал.

Представь, что фронт находится на staging.com, а апишка, к которой он обращается на api.production.com. Фронт хочет отправить json POST’ом. Современные браузеры автоматически отправляют OPTIONS реквесты (которые называются pre-flight), чтобы проверить разрешает ли сервер, чтобы такой запрос с такого-то домена и с такими заголовками отправлялся на сервер.

Для безопасности, по умолчанию, кроме простых запросов, вернётся ошибка ещё на стадии OPTIONS запроса. Для того чтобы этого избежать надо настроить сервер («Access-Contol-Allow-*» заголовки)

О наконец-то есть человек, который разбирается в pre-flight... а объясните, сейчас со стороны браузера действительно считается прогрессивным например вместо одного POST размером 1кб отправить сначала OPTIONS примерно того же размера (учитывая заголовки), а потом уже POST? И если браузер или библиотека не умеют кешировать результат OPTIONS, мы получаем удвоение траффика, и немного увеличиваем нагрузку на сервер, но это хорошо, потому что... что?

Не будет OPTIONS запрос весить 1кб, там не так много информации отправляется. Это не чисто клон «главного» запроса.

Я не считаю себя достаточным специалистом, чтобы объективно оценивать + и — подхода. Но не считаю, что это слишком усложняет или грузит процесс. А по безопасности вроде понятная выгода.

1кб это пример, имелось ввиду, что размеры сопоставимы — заголовки повторяются + 3 дополнительных поля для OPTIONS, что может дать больший размер, чем POST.
А какая выгода по безопасности? Если я пошлю POST и получу access denied это как-то хуже, чем тот же access denied на OPTIONS или отсутствие метода в Access-Control-Allow-Methods?

Не посылаются куки по умолчанию, например.

Что, правда не посылаются? Т.е. если авторизация основана на куках, появляются дополнительные варианты:
— для OPTIONS на сервере куки не нужны, но при этом результат запроса POST никак не будет зависеть от OPTIONS, т.е. можно получить OK c разрешением других методов на OPTIONS и access denied на POST
— на сервере решили отвечать в OPTIONS только списком авторизованных методов, поэтому запрос OPTIONS без куков получил ответ, что POST запрещен, хотя если бы отправляли просто POST, то проблем бы не было...
В общем лично мое мнение, что это очередной придуманный стандарт, без которого все работает, но который, тем не менее все должны знать :)
Кстати, может послать запрос на расширение preflight — посылать HEAD для определения наличия домена и TRACE — просто на всякий случай? :)

Preflight request — это не гарантия того, что какой-то запрос выполнится.

Это просто относительно безопасный способ узнать от сервера, какие запросы можно выполнить с домена фронта.

Поэтому да, основные запросы могут отваливаться из-за авторизации и так далее.

В общем лично мое мнение, что это очередной придуманный стандарт, без которого все работает, но который, тем не менее все должны знать :)

Какие варианты предложишь? Сразу разрешать отправлять любые запросы на любой сервер и с куками?

Согласен, точно так же относительно безопасный способ узнать, безопасна ли дорога для проезда на машине — сначала пройти ее пешком :)
А что не так в отправке запроса с куками на сервер из другого домена? Ведь все равно браузер отправит не все куки, а только те, которые сделаны с этого домена. Кстати, если мы приверяем легитимность фронта, то какая разница, какие куки он отошлет на сервер? Нормальный разработчик бека и так знает, что фронту доверять нельзя и все нужно проверять. Если проверяем легитимность сервера, то почему доверяем ответу OPTIONS?
Собственно можно еще долго рассуждать на эту тему, если бы не одно маленькое НО — далеко не все POST требуют preflight: developer.mozilla.org/...​HTTP/CORS#Simple_requests
Поэтому и получается, что preflight как бы защищает, но как бы немного не всегда :)

Фишка префлайта в том, что это был легкий способ закрыть дыру для всей существующей инфраструктуры, не изменяя ее. Префлайт делает веб secure by default, делает корс по дефолту запрещенным. Для того, чтобы разрешить корс, бекендеру требуется явно совершить определенные действия (в отличие от предложенной тобой валидации поста, где все наоборот).

если браузер или библиотека не умеют кешировать результат OPTIONS

я подозреваю, что такого просто не может быть, так как требование уметь кешировать появилось в стандарте вместе с требованием делать префлайты

Поэтому и получается, что preflight как бы защищает, но как бы немного не всегда :)

Если коротко то оставили для обратной совместимости stackoverflow.com/...​ith-standard-content-type

А что не так в отправке запроса с куками на сервер из другого домена? Ведь все равно браузер отправит не все куки, а только те, которые сделаны с этого домена. Кстати, если мы приверяем легитимность фронта, то какая разница, какие куки он отошлет на сервер?

Браузер отправит все куки того домена, НА который ты шлешь запрос (а не того, С которого).

Проверку легитимности ещё надо включить.

Поясните про выгоду.
По моему опыту, запрос всё равно проходит. Например через консоль или postman. У меня сложилось впечатление, что CORS это чисто браузерная фишка против фишинга, которая обходится на раз-два. Делаешь запросы через «посредника», виртуальный сервак не намного дороже хостинга...

Корс ограничивает только аджакс запросы. Постман и т.п. проходит.
Но, естественно, без ассоциированных с целевым доменом кук.

Это чтобы нельзя было с левого сайта дергать АПИ от имени пользователя (с его куками).

Это не защита от запросов со всех источников.

Не будет OPTIONS запрос весить 1кб, там не так много информации отправляется.

Да один только хендшейк при установке TLS сессии потянет в несколько раз больше килобайта...

со стороны браузера действительно считается прогрессивным

Действительно

объясните, сейчас со стороны браузера действительно считается прогрессивным например вместо одного POST размером 1кб отправить сначала OPTIONS примерно того же размера

К сожалению да

И если браузер или библиотека не умеют кешировать результат OPTIONS

Умеют, на какое-то небольшое время (которое определяется кажется заголовками ответа на опшнс, но лимитировано браузером).

Кроме того, есть nginx, который можно поставить перед апишкой и прописать чтобы он отвечал на опшнс не дергая апи с максимальным кешированием. Заодно балансировку нагрузки можно настроить, отдачу какой-нибудь статики.

Вот примерный конфиг (но может понадобиться модификация под конкретный проект), вставлять нужно в блок location: gist.github.com/michiel/1064640

Ну насчет nginx это и так понятно... кстати, меня еще немного удивило, что претензии вообще предъявляются бекендерам, а не девопсам — я как-то привык, что если это не какой-нибудь проект для себя, то перед ним как минимум ставится reverse proxy, типа nginx, который к тому же распаралеливает нагрузку... (а как максимум — еще и куча железа по дороге) ну и все подобные настройки сваливаются на этот самый прокси, но никак не на бекенд

Кому мог, тому и предъявил.

На самом деле по-разному можно делать. Если приложению нужны какие-либо сложные правила, то может быть необходимость делать это исключительно на бэкэнде. Или если бэк запускается локально для разработки, вполне может там быть обработка опшнс, а в проде на опшнс отвечает нгинкс. Тем более, одним префлайтом дело не заканчивается и каждый запрос должен включать в ответ специальный заголовок. А добавлять заголовки на нгинкс в каждый запрос — ну не знаю, мне так себе идея.

Представь, что фронт находится

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

Якби я писав статтю про проблеми індійців і шерифа то використав би це як приклад )

Способом, описанным в документации апишки, которую создал бэкенд дев?

Бэкэнд часто делают реиспользуемым со стороны разных клиентов, с разными протоколами/итп.

И тут сам разраб конкретного клиента решает, что ему нужно дописать к бэкэнду — чтобы дёргать API бэкэнда из UI нужным образом.

Спасибо за ответ.

В мире простых CRUD’ов тоже такое происходит?

При простому круді все робить фулстьок

Потому что бэкэндер вообще может не знать каким способом вы дергаете сервер.

потому что в Украине бэкэндер вообще может дупля не отбивать что за приложение он пишет и зачем оно нужно

Я про CORS дізнався вже маючи 3 роки досвіду, а до цього спокійно розробляв без цих знань

Это странно для меня (ситуация в целом), так как когда я начал смотреть курсы по Ноду, эта тема была в разделе 101

Я читал три огромных талмуда по ASP.net: вебформам, мвц и кору. Про корс было только по кору, в конце и походя.

Это потому что в первых двух UI и сервер обычно деплоят на один хост, в одном процессе, там проблема CORS не стоит.

«По ноду» — може в тому і причина ? От создатєлєй запуска бекенда на хромє.

бекенда на хромє.

аж передернуло ска

Странный ты курсы по ноде смотрел, хотя такие курсы могут объяснить львиную долю проектов на ноде

To man with a hammer everything looks like a nail :) Это чисто браузерный костыль, а протоколом HTTP внезапно не только браузеры пользуются. И в спецификации протокола, например, вы CORS заголовков не обнаружите даже в виде намеков, емнип.

И? Человек, который пишет апи для веба не должен знать что это и как с ним работать?

Для того, чтобы два приложения могли между собой общаться по HTTP никакие CORS заголовки не нужны в общем случае. Они появляются только тогда, когда одно из этих приложений — браузер (и то не всякий). Понимаю, звучит невероятно для фронтендера, но в общем случае среди клиентов среднестатистической апишки браузеры просто не значатся :) Так что не знать (или забыть) о корс для бэкендера вполне простительно. Тем более, что пробел этот заполняется за полчаса курения документации...

(и то не всякий)

Всякий, на который стоит ориентироваться.

Помогите понять тогда, какой будет среднестатистический клиент апишки?

Спроси у представителя заказчика

Не редко апи пишется под мобильные устройства, а они болт клали на весь это CORS. Так же всякое api может же быть эндпойнтом как для пользователя так и для интеграции сторонних приложений. Фактически CORS нужен только для браузера так как иначе это может быть дыра в безопасности и можно по тихому вытягивать данные из других сервисов которыми человек пользуется.

Ок, согласен.

Но не кажется ли вам это немного притянутым за уши, когда разработка идёт под веб?

Но не кажется ли вам это немного притянутым за уши, когда разработка идёт под веб?

Если разработка идет под веб то настройкой CORS скорее всего занимаются ответственные за деплой люди, а не бекенд девы. Да знать такие вещи стоит, но не больше чем в общих чертах.

Запрещает запросы с других доменов. Например, я создал свой сайт и с него отправляю запросы на получение приватных данных пользователя в фейсбуке, если пользователь в фейсбуке залогинен.

У нас было две апы под анроид и ось без веб-версии и бекенд для них вот про это вот ваше все браузерное хозяйство вообще н е знает:)

ну как ни крути но браузер самый популярный хттп клиент

еще руки должен мыть садясь за рабочее место...

Почему костыль ? Вполне рабочий вариант не дать браузеру слать запросы куда не надо втихаря для пользователя.

Каким образом CORS мешает слать запросы втихаря?

Каким образом CORS мешает слать запросы втихаря?

Просто отправить запрос можно, а вот отправить запрос с куками для другого сайта так, чтоб еще и пользователь не знал про это не выйдет. Если вы воспользуетесь прокси то куки браузер не отправит, а без этого попасть можно только в общедоступные разделы сайта.

Потому что это не базовые вещи для бекенда. не были, и не будут.

Да и для фронтенда — когда спрашиваешь, посылают на стековерфлоу.

Почему я — фронт — знаю об этом больше,

покажите им свои знания в виде спецификации, по которой они обязаны настроить вам API

То есть вещи, которые нужно настроить для того, чтобы иметь возможность делать запросы это не базовые ?

Еще OSI вспомни, и разберись, как оптимально настроить nginx

В курсах по ноде этот вопрос шёл в разделе 101

В любом случае спасибо за мнение

а зачем бекендеру курсы по ноде?

+1
если это нужно для компании — сделайте стандартом и задомументируйте.
Если интересный вопрос сколько человек это использует и откуда инициатива — разберитесь с архитектурой внутри команды\компании
и задокументируйте

Что собственно документировать?

Все в курсе, что разработка под веб. Браузеры работают именно так, что настройка нужна.

все в курсе что в телевизоре есть микросхемы

Что собственно документировать?

ВАШИ потребности

Браузеры работают именно так

Браузер — это ПО на клиенте
бек не занимается разработкой клиентов
соответственно и не обязан знать что там на клиенте какой софтине надо

А знать как отвечать на какие запросы он обязан?

По требованиям для проекта и задачам в баг трекере.
За все остальное заказчик не платит, и занятие остальным в рабочее время считается саботажем.

не обязан, если ему не была поставлена такая задача.

Яких «базових вещей»? Не можна так просто взяти і налаштувати CORS в Spring Security — там кучка нюансів по ходу вилазить. :)

это как раз их часть работы

Не совсем. CORS — это браузерная специфика и это в первую очередь ответственность фронта понимать как работает браузер и быть способным сформулировать внятные требования к апи в том числе на уровне хедеров.

Хотите сказать, что разраб пишет апишку и не в курсе какие сервер будет ожидать заголовки ?

конечно.
бекендер часто вообще «не знает ничего» о транспортном уровне.

То есть бэк такой пишет CRUD для веба, распарсивает json от клиента,...

router.post('/add-product', (req, res) => { ... });

А потом такой внезапно: Я не в курсе какие ты там заголовки отправляешь, в каком формате данные идут, я ничего не знаю о транспортном уровне.

То, что фронт команда с локалхоста отправляет запросы он тоже не в курсе, так как спал на митингах.

Так это работает?

так как спал на митингах.

обратитесь к вашему лиду.
пусть разгонит вашу бек команду.

только, я вам по секрету скажу, скорее выгонят вас, как скандалиста который пытается обязать делать работу — нужную ему

еще раз, беку было и будет плевать на ваши фронт заморочки

То, что фронт команда с локалхоста отправляет запросы он тоже не в курсе, так как спал на митингах.

и
любой имеет полное право «спать на митинге»

что не записано — того и не было.
потырендели там что-то свое фронтендеры, ну и ладно.

это опять же, из опыта — когда зовешь фронт — народ, давайте спеку напишем!
«та нам все равно, какую напишите такая и будет»

так что вы не на доу, вы к лидам своим приставайте. пусть вам правильных бекендеров найдут :)

что не записано — того и не было

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

постараюсь зампонить.

постарайтесь.

приложение под веб делается

и чем отличается для бекендера приложение «под веб» и «не под веб» — тоже постарайтесь разобраться. тогда может и сможете объяснить наконец бекендерам. До сих пор, как понял, у вас не получалось ;)

Что собственно документировать?
ВАШИ потребности
еще раз, беку было и будет плевать на ваши фронт заморочки

Ну такое, иногда подгорает от такого отношения к решению задач. Даже хз как это назвать. Типа, — сидишь целыми днями, кнопаешь что-то, и совершенно плевать зачем ты это делаешь, как бот какой то.
Утрированная аналогия, — Коллега идет в магаз, просишь человека купить чего-то поесть, а он приносит мешок картохи и живую рыбину.
Вроде всё логично. Есть можно? Можно. Типа сам виноват, что не уточнил какую еду принести...

такого отношения к решению задач

Задачи должны быть расписаны «как для тупых». Если задача детально не расписана — результат работы достаточно случайный (ССЗБ).

Задачи должны быть расписаны «как для тупых».

Это если с тупыми работаешь, наверное. Вменяемым разработчикам будет грустно делать такие over-specified таски.

Если не указать, как должен работать результат, то вместо крокодила получишь стрекозу. Или наоборот. Проверено. Потом пишутся баги, что все не так, как надо.

Попробуй дать двум людям задачу написать модули, взаимодействующие друг с другом, не нарисовав API. Оно заработает? А почему? Оба — девелоперы, оба шарят. А потому, что каждый понимает по-своему, и делает как понимает. И в результате «оптимальный» API у разных людей выглядит по-разному для одного и того же функционала.

Так это совсем другое, API контракты, как раз, нужно детально прописывать, а вот детали реализации стоит отавлять разработчику, чтобы он от скуки не ушел через дорогу на +500.

Я не про детали реализации, а про требуемое поведение.
Если описано «должно работать с файрфоксом и показывать зеленое окошко» — либо девы либо тестеры проверят с файрфоксом.
Если написано «сделать API для получение списка клиентов» — будет API в вакууме, но не жалуйтесь, если не работат с файрфоксом.

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

На уровне каждого отдельного круда о корсах точно никто не думает. Раз настроили и забыли. Да и круд может дергаться не только из браузера внезапно.

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

Я же не создаю вопрошаю сообщество, почему фронтендеры просят бэкендеров отсортировать некий массив

А вы спросите. Особенно тех, кто просит об этом.

А «перетягивание одеяла» кому сортировать надо. Да, я понимаю, порой возникают вопросы.

Вот вопрошающих и спрашивал и с ними же ругался по этому поводу)

им неохота красивенький фронтенд код загрязнять такими мелочами

Любителей спихнуть работу на другую сторону предостаточно. Хотя есть ситуации, где действительно логичнее сделать сортировку на бэке.

Конечно есть. Но если сортировка диктуется исключительно от порядка расположения контролов на страничке бо так нарисовал дизайнер, то в топку

Если бы позволяли обстоятельства, то я бы поступил так:
1. Сделал
2. Зарепортил
3. На перформанс ревью и ему подобных митингах упоминал бы об этом

На основании этого проще выторговать себе повышения, без перехода на 500+ :)

3.

4. Говорил бы что фронтендеры ничего не делают

То есть бэк такой пишет CRUD для веба

Твоя ошибка как раз таки в том, что ты считаешь что «бекенд/АПИ» == «CRUD для веба».
Спешу тебя удивить — это не так.

Фронт команда в локалхосте не знает как отключить web security или как поставить allow cors экстеншн в хроме? Вы понимаете что на проде никто корс не настраивает и все идет через реверс проксю, и при этом заявляете о баге на бэкенде?

Да серверу плевать слюной на CORS заголовки, они браузеру нужны.

Угу, сами придумали, сами обижаются)

Нужны браузеру, полученные от сервера.

Да врачу плевать слюной на лечение пациента, оно больному нужно

Именно.
В этом суть АПИ как такового. АПИ — провайдер. Провайдеру пофиг, какие у него будут клиенты, АПИ и есть для разделения ответственности и проложения контракта между провайдером сервиса и клиентом.

Более того, учитывая, что CORS — это особенность браузеров, а HTTP используется не только для общения с браузером, то настройка CORS на бекенде является как раз нарушением разделения ответствености.

Или же, в спецификации к АПИ должно быть отдельно указано, что вот это вот и это требует CORS.

Почему я — фронт — знаю об этом больше

молодец, садись 5, кто ж тебя не похвалит как не ты сам...

Подписаться на комментарии