Узнайте, как использовать возможности Laravel CORS в этом руководстве. Узнайте, что это такое, и раскройте его потенциал для беспрепятственного совместного использования ресурсов между источниками.
Laravel уже довольно давно поддерживает CORS; Однако до более поздних версий он был только из сторонних пакетов. Давайте углубимся в CORS в Laravel, что это такое и почему это важно.
CORS расшифровывается как Cross-Origin Resource Sharing. Это механизм, который позволяет вам безопасно делать запросы к домену, отличному от вашего собственного. Он определяет набор заголовков, которые сервер может использовать для управления тем, какие источники могут получить доступ к его ресурсам. Но что это значит для вас?
Как человек, который создает много API, я очень привык к CORS. На данный момент это стало второй натурой. Laravel по умолчанию имеет встроенную поддержку CORS, откуда он будет считывать данные config/cors.php для программного создания правил защиты на основе настроенных значений. Давайте рассмотрим параметры в этом файле, чтобы увидеть, что они значат для нас.
Пути Наш
первый вариант - это пути, которые по умолчанию имеют следующее:
'paths' => ['api/*', 'sanctum/csrf-cookie'],
В этом варианте мы указываем программному обеспечению промежуточного слоя CORS соответствовать любым запросам, перечисленным здесь, и позволяем CORS перейти к следующей проверке. Если входящий запрос не соответствует какому-либо шаблону, который мы добавляем в нашу конфигурацию, мы автоматически блокируем любые запросы от внешних хостов.
Методы Наш
следующий вариант - это разрешенные методы, которые по умолчанию настроены следующим образом:
'allowed_methods' => ['*'],
По умолчанию Laravel позволяет передавать любой метод извне, а это означает, что интеграция API не требует каких-либо особых соображений. Здесь вы можете быть настолько строгими или расслабленными, насколько захотите. Это полностью зависит от вас. Обычно я оставляю здесь значение по умолчанию, так как большинство API, которые я обычно создаю, в некоторых отношениях требуют полного внешнего контроля. Если бы мы изменили это на:
'allowed_methods' => ['GET', 'POST','PUT','PATCH'],
Это означало бы, что мы хотим отклонять любые внешние запросы, которые явно являются запросом или запросомDELETE, не указанным в конфигурации CORS. Если у вас есть общедоступный API, доступный только для чтения, вы, скорее всего, настроите его по-другому.
Происхождение Далее
мы рассмотрим разрешенные источники, которые по умолчанию настроены следующим образом:
'allowed_origins' => ['*'],
По умолчанию мы говорим, что мы разрешим входить соединения или запросы из любого источника (также известного как IP-адрес или сервер). Если бы мы создавали внутренние API, мы бы постарались настроить это либо на диапазон IP-адресов, либо ограничить его определенными доменами. Это поможет защитить вас от людей, делающих запросы из мест, которые вы, возможно, не хотите. Опять же, если ваш API является общедоступным, вы, скорее всего, оставите его как есть. Пожалуйста, запомните этот параметр, если у вас возникнут проблемы CORS при интеграции с вашим API.
Вы можете использовать дополнительную часть конфигурации, чтобы быть менее конкретным и больше полагаться на соответствие регулярных выражений. Это разрешенные шаблоны источников, где вы можете добавить регулярное выражение, чтобы проверить источник запроса, чтобы увидеть, принимаются они или отклоняются. По умолчанию это пустой массив, так как здесь вы должны быть осторожны:
'allowed_origins_patterns' => [],
Заголовки
Вы можете быть настолько строгими или расслабленными, насколько вам нужно быть с заголовками, когда дело доходит до конфигурации CORS. Эта часть конфигурации позволяет вам установить, какие заголовки разрешены из сторонних источников при поступлении запроса. Допустим, вы хотите быть очень конкретными, чтобы внешние стороны могли делать запросы только в определенных типах контента или принудительно принимать определенные типы контента. Это маловероятно, но хороший пример. В некоторых API, особенно несколько лет назад, я добавлял промежуточное ПО приложений, которое проверяло, принимают ли они JSON, и отклоняло с предупреждением, если его не было. Мы можем сделать то же самое здесь, но только для третьих лиц. Однако по умолчанию в Laravel выглядит следующим образом:
'allowed_headers' => ['*'],
Exposing Заголовки
Exposing Заголовки is a funny one. Chances are you will not need it - but if you do, it will take ages to figure out that you need it! The default configuration looks like the following:
'exposed_headers' => [],
Поэтому, чтобы понять, что сюда добавить, если вам это нужно, вам нужно понять, что или кто с вами интегрируется. Как правило, проблемы CORS здесь связаны с правилами браузера с CORS и запросами CORS, где заголовки удаляются, поскольку они считаются небезопасными. Допустим, у вас есть заголовки, которые не являются заголовками по умолчанию, такие как: или X-GITHUB-ID что-то в этом роде, по умолчанию они будут удалены в запросах CORS, что, в свою очередь, может вызвать непреднамеренные побочные эффекты, X-VAPOR-ENCODE о которых вы не знали.
Максимальный возраст Мы
можем настроить, как долго клиенты могут кэшировать ресурсы для использования этого параметра в конфигурации CORS.
'max_age' => 0,
По умолчанию мы настраиваем это так, чтобы клиенты ничего не кэшировали из нашего приложения. Это, однако, гибко, так как только интеграции, такие как браузеры, будут полностью уважать это.
Учетные данные Наконец
, у нас есть опция учетных данных поддержки. Этот параметр по умолчанию установлен на false:
'supports_credentials' => false,
Здесь мы настраиваем, хотим ли мы разрешить аутентификацию из сторонних источников. Это то, к чему нужно быть очень внимательным, потому что, если вы установите для этого значение true, люди могут войти в систему и получить данные аутентификации. Если мы установим это на true, вы откроете себя для потенциальных фишинговых атак на ваших пользователей, что может привести к дальнейшим проблемам. Если вам нужно установить значение true, убедитесь, что другие параметры точны, чтобы вы могли контролировать, кто может это делать. Последнее, что вы хотите сделать, это разрешить все запросы из любого источника, поддерживающего учетные данные!
Это было лишь пошаговое руководство о том, что можно сделать с конфигурацией и что каждый параметр означает для вас и вашего приложения. Всегда следите за тем, чтобы вы были осторожны при настройке конфигурации и правил CORS, потому что вы не хотите подвергать себя и, соответственно, своих пользователей любым потенциальным атакам из-за неправильной конфигурации.
