Thank you for reading this post, don't forget to subscribe!

ста­тью нуж­но было назвать ЕБУЧИЙ CORS но это не политкорректно.

CORS, так­же извест­ный как сов­мест­ное исполь­зо­ва­ние ресур­сов из раз­ных источ­ни­ков, – это метод, исполь­зу­е­мый в совре­мен­ных веб-бра­у­зе­рах, кото­рый кон­тро­ли­ру­ет доступ к ресур­сам, раз­ме­щен­ным на веб-сер­ве­ре. CORS исполь­зу­ет допол­ни­тель­ные заго­лов­ки, такие как origin, access-control-origin и мно­гие дру­гие, что­бы опре­де­лить, есть ли у запро­шен­но­го ресур­са раз­ре­ше­ние на отправ­ку в бра­у­зер. Основ­ная цель CORS – предот­вра­тить доступ веб-при­ло­же­ния, запу­щен­но­го в веб-бра­у­зе­ре, к ресур­сам, раз­ме­щен­ным в дру­гом источ­ни­ке, когда нет раз­ре­ше­ния, что озна­ча­ет, что веб-при­ло­же­ние не может загру­жать ресур­сы, такие как изоб­ра­же­ния, скрип­ты, CSS, напри­мер любой кон­тент и т. д., если они не раз­ме­ще­ны в том же самом источ­ни­ке (обыч­но все долж­ны нахо­дить­ся в том же домене), что и веб-при­ло­же­ние, если толь­ко сер­вер не настро­ен на такое пове­де­ние. Имея эту реа­ли­за­цию в веб-бра­у­зе­ре, поль­зо­ва­те­ли могут защи­тить свои дан­ные от неав­то­ри­зо­ван­ных сто­рон. Хакер может тай­но изме­нить веб-стра­ни­цу, нахо­дясь в сере­дине соеди­не­ния, что­бы нару­шить рабо­ту поль­зо­ва­те­ля или полу­чить доступ к цен­ным дан­ным. Одна­ко у CORS есть и пре­иму­ще­ства, напри­мер, он поз­во­ля­ет раз­ра­бот­чи­кам загру­жать ресур­сы из дру­го­го источ­ни­ка из-за эко­но­ми­че­ской эффек­тив­но­сти или про­сто удоб­ства. В этом слу­чае они долж­ны изме­нить свой веб-сер­вер, что­бы раз­ре­шить такие запросы

Что вызывает запрос CORS

Не все запро­сы вызы­ва­ют запрос CORS, посколь­ку обыч­но ресур­сы раз­ме­ща­ют­ся в том же источ­ни­ке, что и веб-при­ло­же­ние. Если он дру­гой, то сра­ба­ты­ва­ет CORS. CORS име­ет два типа запро­сов: про­стой запрос и пред­ва­ри­тель­ный запрос CORS.

Про­стой запрос рабо­та­ет как обыч­ный запрос, веб-бра­у­зер отправ­ля­ет запрос на сер­вер для загруз­ки опре­де­лен­но­го ресур­са, когда поль­зо­ва­тель его ини­ци­и­ро­вал, затем веб-сер­вер про­ве­ря­ет источ­ник запро­са, срав­ни­ва­ет его с пра­ви­ла­ми на веб-сер­ве­ре, если он сов­па­да­ет, ресурс предо­став­ля­ет­ся. Этот тип запро­са исполь­зу­ет заго­лов­ки OIRIGN и ACCESS-CONTROL-ALLOW-ORIGIN, что­бы опре­де­лить, сле­ду­ет ли предо­став­лять ресурс или нет. Про­стой запрос запус­ка­ет­ся толь­ко в том слу­чае, если исполь­зу­ют­ся такие мето­ды запро­са, как GET, HEAD, POST, и заго­лов­ки, такие как Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width. Даже в этом слу­чае не все типы кон­тен­та вызы­ва­ют про­стой запрос. Здесь толь­ко типы коди­ро­ва­ния фор­мы вызы­ва­ют про­стой запрос.

Тип пред­ва­ри­тель­но­го запро­са несколь­ко отли­ча­ет­ся, посколь­ку в пер­вом раун­де нет пря­мо­го досту­па к ресур­сам. Когда выше­упо­мя­ну­тые усло­вия каким-либо обра­зом изме­ня­ют­ся, либо с исполь­зо­ва­ни­ем дру­го­го заго­лов­ка запро­са, либо дру­го­го типа кон­тен­та, запус­ка­ет­ся пред­ва­ри­тель­ный запрос. В пред­ва­ри­тель­ных запро­сах веб-бра­у­зер сна­ча­ла про­ве­ря­ет, может ли он полу­чить доступ к ресур­су, вза­и­мо­дей­ствуя с веб-бра­у­зе­ром, а затем, когда веб-бра­у­зер отве­ча­ет поло­жи­тель­ным (HTTP 200) отве­том, он отправ­ля­ет еще один запрос на загруз­ку ресур­са. Он исполь­зу­ет метод запро­са HTTP OPTION для ини­ци­и­ро­ва­ния пер­во­го запро­са, затем он исполь­зу­ет типы запро­сов GET, POST для загруз­ки ресурсов.

Как настроить Nginx для поддержки запросов CORS

В этом раз­де­ле пока­за­но, как настро­ить веб-сер­вер nginx, что­бы раз­ре­шить сов­мест­ное исполь­зо­ва­ние ресур­сов из раз­ных источ­ни­ков. Это мож­но сде­лать толь­ко в том слу­чае, если у раз­ра­бот­чи­ка есть доступ к веб-сер­ве­ру, так как это пред­по­ла­га­ет изме­не­ние фай­ла кон­фи­гу­ра­ции Nginx.

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

Базо­вый фраг­мент кода выгля­дит так, как ука­за­но выше. Он содер­жит такие дирек­ти­вы, как request_method, add_header, для опре­де­ле­ния типа запро­са и уста­нов­ки заго­лов­ка отве­та для чте­ния бра­у­зе­ром соот­вет­ствен­но. Заго­ло­вок Access-control-allow-origin опре­де­ля­ет, к како­му источ­ни­ку име­ет доступ ресурс, напри­мер, если веб-при­ло­же­ние, раз­ме­щен­ное в github, хочет полу­чить доступ к изоб­ра­же­нию, раз­ме­щен­но­му на myOwnServer.ru, тогда URL-адрес github дол­жен исполь­зо­вать­ся в каче­стве зна­че­ния Дирек­ти­ва Access-control-allow-origin в myOwnServer.ru, затем вся­кий раз, когда веб-при­ло­же­ние, раз­ме­щен­ное в github, отправ­ля­ет запро­сы на myOwnServer.ru для загруз­ки фай­ла изоб­ра­же­ния, всем этим запра­ши­ва­е­мым предо­став­ля­ет­ся раз­ре­ше­ние. Заго­ло­вок Access-control-allow-method опре­де­ля­ет, какие типы запро­сов под­дер­жи­ва­ет веб-при­ло­же­ние, отправ­ля­ю­щее запро­сы, тогда осталь­ные заго­лов­ки пред­на­зна­че­ны для мак­си­маль­но­го воз­рас­та для кэши­ро­ва­ния запросов,

Как опи­са­но выше, как толь­ко запрос OPTION был завер­шен, бра­у­зер отправ­ля­ет дру­гой запрос на загруз­ку ресур­сов, если пер­вый запрос был успеш­ным, его заго­лов­ки уста­нав­ли­ва­ют­ся в пер­вом request_method, если скобки.

Поми­мо выше­упо­мя­ну­тых дирек­тив, в Nginx есть неко­то­рые дру­гие важ­ные дирек­ти­вы, кото­рые мож­но исполь­зо­вать в запро­сах CORS. Одна из наи­бо­лее важ­ных дирек­тив – access-control-allow-headers, она уста­нав­ли­ва­ет заго­ло­вок отве­та с раз­ре­шен­ны­ми име­на­ми заго­лов­ков для про­вер­ки бра­у­зе­ром. Веб-при­ло­же­ние может иметь свои соб­ствен­ные заго­лов­ки для раз­лич­ных целей, и если такие заго­лов­ки при­сут­ству­ют в после­ду­ю­щих запро­сах после началь­но­го запро­са OPTIONS, то все эти заго­лов­ки долж­ны быть раз­ре­ше­ны веб-сер­ве­ром до того, как запра­ши­ва­е­мый ресурс будет сов­мест­но использован.

Важ­но, что­бы этот фраг­мент кода нахо­дил­ся в нуж­ном месте в фай­ле по умол­ча­нию Nginx, пото­му что Nginx выпол­ня­ет раз­ные бло­ки место­по­ло­же­ния в зави­си­мо­сти от сопо­став­лен­но­го URL-адре­са, если такой блок место­по­ло­же­ния не содер­жит этот фраг­мент кода, он вооб­ще не выпол­ня­ет­ся, и поэто­му важ­но исполь­зо­вать это во всех бло­ках лока­ции на вся­кий слу­чай. Неко­то­рые из важ­ных бло­ков место­по­ло­же­ния – это бло­ки изоб­ра­же­ний, PHP (~ \.php$), CSS и т. д.

После сохра­не­ния выше­упо­мя­ну­то­го фраг­мен­та кода сохра­ни­те файл Nginx и пере­за­гру­зи­те служ­бу Nginx, что­бы изме­не­ния всту­пи­ли в силу.