Дізнайтеся, як використовувати потужність Laravel CORS у цьому уроці. Дізнайтеся, що це таке, і розкрийте його потенціал для безперебійного спільного використання ресурсів між джерелами.
Laravel підтримує CORS протягом тривалого часу; Однак до пізніших версій він був лише зі сторонніх пакетів. Давайте зануримося в CORS в Ларавелі, що це таке, і чому це важливо.
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.
Ви можете використовувати додаткову частину конфігурації, щоб бути менш конкретною та більше спиратися на відповідність регексу. Це дозволені шаблони походження, де ви можете додати regex, щоб перевірити походження запиту, щоб побачити, приймаються вони чи відхиляються. За замовчуванням це порожній масив, оскільки ви хочете бути обережними тут:
'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-VAPOR-ENCODE або X-GITHUB-ID щось подібне, за замовчуванням вони будуть видалені із запитів CORS, що, у свою чергу, може спричинити ненавмисні побічні ефекти, про які ви не знали.
Максимальний вік Ми
можемо налаштувати, як довго клієнти можуть кешувати ресурси для використання цієї опції в конфігурації CORS.
'max_age' => 0,
За замовчуванням ми налаштовуємо це так, щоб клієнти нічого не кешували з нашого додатка. Це, однак, є гнучким, оскільки лише інтеграції, такі як браузери, повністю поважатимуть це.
Облікові дані
Нарешті, у нас є опція облікових даних підтримки. Цей параметр за замовчуванням встановлено на false:
'supports_credentials' => false,
Що ми тут налаштовуємо, чи хочемо ми дозволити автентифікацію від сторонніх джерел. Це те, до чого слід бути дуже уважним, тому що якщо ви встановите для цього значення true, люди зможуть увійти в систему та повернути дані автентифікації. Якщо ми встановимо це як true, ви відкриєте себе для потенційних фішингових атак на своїх користувачів, що може призвести до подальших проблем. Якщо вам потрібно встановити для нього значення true, переконайтеся, що інші параметри точні, щоб ви могли контролювати, хто може це робити. Останнє, що ви хочете зробити, це дозволити всі запити з будь-якого походження, яке підтримує облікові дані!
Це було лише покроковим посібником з того, що можна зробити з конфігурацією та що кожен варіант означає для вас та вашої програми. Завжди будьте обережні при налаштуванні конфігурації та правил CORS, оскільки ви не хочете відкривати себе і, як наслідок, своїх користувачів до будь-яких потенційних атак через неправильну конфігурацію.
