• Czas czytania ~4 min
  • 11.07.2023

Dowiedz się, jak wykorzystać moc Laravel CORS z tego samouczka. Odkryj, co to jest i uwolnij jego potencjał do bezproblemowego udostępniania zasobów między źródłami.

Laravel wspiera CORS od dłuższego czasu; Jednak do nowszych wersji pochodził tylko z pakietów innych firm. Zanurzmy się w CORS w Laravel, co to jest i dlaczego jest ważne.

CORS oznacza Cross-Origin Resource Sharing. Jest to mechanizm, który pozwala bezpiecznie wysyłać żądania do innej domeny niż własna. Definiuje zestaw nagłówków, których serwer może używać do kontrolowania, które źródła mogą uzyskiwać dostęp do jego zasobów. Ale co to oznacza dla ciebie?

Jako ktoś, kto buduje wiele interfejsów API, jestem bardzo przyzwyczajony do CORS. W tym momencie stało się to drugą naturą. Laravel, domyślnie, ma wbudowaną obsługę CORS, gdzie będzie odczytywał w config/cors.php celu programowego zbudowania reguł ochrony na podstawie skonfigurowanych wartości. Przejdźmy przez opcje w tym pliku, aby zobaczyć, co dla nas znaczą.

Ścieżki

Naszą pierwszą opcją są ścieżki, które domyślnie mają następujące elementy:

'paths' => ['api/*', 'sanctum/csrf-cookie'],

W tej opcji mówimy oprogramowaniu pośredniczącemu CORS, aby pasowało do wszystkich wymienionych tutaj żądań i pozwoliło CORS przejść do następnego sprawdzenia. Jeśli przychodzące żądanie nie pasuje do żadnego wzorca dodanego do naszej konfiguracji, automatycznie zablokujemy wszystkie żądania od hostów zewnętrznych.

Następną

opcją są dozwolone metody, które domyślnie są skonfigurowane w następujący sposób:

'allowed_methods' => ['*'],

Domyślnie Laravel zezwala na przekazywanie dowolnej metody na zewnątrz, co oznacza, że integracja API nie wymaga żadnych specjalnych rozważań. Możesz być tak surowy lub zrelaksowany, jak chcesz. To zależy wyłącznie od Ciebie. Zwykle zachowuję tutaj domyślne ustawienia, ponieważ większość interfejsów API, które zwykle tworzę, wymaga pełnej kontroli zewnętrznej pod pewnymi względami. Gdybyśmy zmienili to na:

'allowed_methods' => ['GET', 'POST','PUT','PATCH'],

Oznaczałoby to, że chcemy odrzucić wszystkie żądania zewnętrzne, które są jawnie żądaniem lub żądaniem DELETE niewymienionym w konfiguracji CORS. Jeśli masz publiczny interfejs API tylko do odczytu, bardziej prawdopodobne jest, że skonfigurujesz to inaczej.

Następnie

przyjrzymy się dozwolonym źródłom, które domyślnie są skonfigurowane w następujący sposób:

'allowed_origins' => ['*'],

Domyślnie mówimy, że zezwalamy na połączenia lub żądania z dowolnego źródła (znanego również jako adres IP lub serwer). Gdybyśmy budowali wewnętrzne interfejsy API, staralibyśmy się skonfigurować je do zakresu adresów IP lub ograniczyć to do określonych domen. Pomaga to chronić Cię przed osobami wysyłającymi żądania z lokalizacji, których możesz nie chcieć. Ponownie, jeśli Twój interfejs API jest publiczny, prawdopodobnie zachowasz go takim, jaki jest. Pamiętaj o tym ustawieniu, jeśli masz problemy z CORS podczas integracji z interfejsem API.

Możesz użyć dodatkowej części konfiguracji, aby być mniej szczegółowym i bardziej polegać na dopasowywaniu wyrażeń regularnych. Jest to dozwolone wzorce pochodzenia, w których można dodać wyrażenie regularne, aby sprawdzić pochodzenie żądania, aby sprawdzić, czy są one akceptowane lub odrzucane. Domyślnie jest to pusta tablica, ponieważ będziesz chciał być ostrożny

'allowed_origins_patterns' => [],

tutaj:

Nagłówki Możesz być tak surowy lub zrelaksowany, jak to konieczne w przypadku nagłówków, jeśli chodzi o konfigurację CORS. Ta część konfiguracji umożliwia ustawienie, jakie nagłówki są dozwolone ze źródeł innych firm, gdy nadejdzie żądanie. Załóżmy, że chcesz być bardzo konkretny, aby strony zewnętrzne mogły wysyłać żądania tylko w określonych typach zawartości lub wymuszać akceptowanie określonych typów zawartości. Jest to mało prawdopodobne, ale dobry przykład. W niektórych API, szczególnie kilka lat temu - dodawałem oprogramowanie pośredniczące aplikacji, które sprawdzało, czy akceptują JSON i odrzucało z ostrzeżeniem, jeśli nie było na miejscu. Możemy zrobić to samo tutaj - ale tylko dla osób trzecich. Domyślne ustawienie w Laravel wygląda jednak następująco:

'allowed_headers' => ['*'],

Exposing tutaj:

Exposing tutaj: 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' => [],

Aby zrozumieć, co dodać tutaj, jeśli tego potrzebujesz, musisz zrozumieć, co lub kto integruje się z tobą. Zazwyczaj problemy z CORS są związane z regułami przeglądarki z żądaniami CORS i CORS, w których nagłówki są usuwane, ponieważ są uważane za niebezpieczne. Załóżmy, że masz nagłówki, które nie są domyślne, takie jak: lub X-GITHUB-ID coś w tym stylu, domyślnie zostaną one usunięte na żądanie CORS, X-VAPOR-ENCODE co z kolei może spowodować niezamierzone skutki uboczne, których nie byłeś świadomy.

Maksymalny wiek

Możemy skonfigurować czas, przez jaki klienci mogą buforować zasoby w celu użycia tej opcji w konfiguracji CORS.

'max_age' => 0,

Domyślnie konfigurujemy to, aby klienci nie buforowali niczego z naszej aplikacji. Jest to jednak elastyczne, ponieważ tylko integracje, takie jak przeglądarki, będą w pełni to respektować.

Poświadczenia

Wreszcie mamy opcję poświadczeń wsparcia. Ta opcja jest domyślnie ustawiona na false:

'supports_credentials' => false,

To, co tutaj konfigurujemy, to czy chcemy zezwolić na uwierzytelnianie ze źródeł zewnętrznych. Jest to coś, co należy bardzo rozważyć, ponieważ jeśli ustawisz to na true, ludzie mogą się zalogować i odzyskać szczegóły uwierzytelnienia. Jeśli ustawimy to na true, otworzysz się na potencjalne ataki phishingowe na swoich użytkowników, co może prowadzić do dalszych problemów. Jeśli musisz ustawić go na true, upewnij się, że inne opcje są precyzyjne, abyś mógł kontrolować, kto może to zrobić. Ostatnią rzeczą, którą chcesz zrobić, to zezwolić na wszystkie żądania z dowolnego źródła, które obsługuje poświadczenia!

To był tylko przewodnik po tym, co można zrobić z konfiguracją i co każda opcja oznacza dla Ciebie i Twojej aplikacji. Zawsze upewnij się, że jesteś ostrożny podczas konfigurowania konfiguracji i reguł CORS, ponieważ nie chcesz narażać siebie, a co za tym idzie, swoich użytkowników na potencjalne ataki z powodu niewłaściwej konfiguracji.

Comments

No comments yet
Yurij Finiv

Yurij Finiv

Full stack

O

Professional Fullstack Developer with extensive experience in website and desktop application development. Proficient in a wide range of tools and technologies, including Bootstrap, Tailwind, HTML5, CSS3, PUG, JavaScript, Alpine.js, jQuery, PHP, MODX, and Node.js. Skilled in website development using Symfony, MODX, and Laravel. Experience: Contributed to the development and translation of MODX3 i...

O autorze CrazyBoy49z
WORK EXPERIENCE
Kontakt
Ukraine, Lutsk
+380979856297