Trochę nie do końca się zgadzam z definicją CORS. każda przeglądarka blokuje zapytania między różnymi origin, a CORS właśnie umożliwia dzielenie się tymi zasobami a nie blokuje te zasoby. Blokowanie jest w każdej przeglądarce od zawsze (od kiedy wszedł AJAX).
Jak nie macie możliwości ustawienia corsów na backendzie możecie użyć servera proxy który symuluje/zastępuje odpowiedni adres ( w React to jedna linijka kodu)
fajne wyjaśnienie! 6:30 skoro można wyłączyć politykę cors w przeglądarce to po wyłączeniu można wykonywać już zapytania do innych originów? Jeżeli tak to po co ten cors skoro można go wyłączyć i łatwo go obejść?
Można samemu u siebie go wyłączyć, ale 99,9% użytkowników internetu i tak ma go domyślnie włączonego w przeglądarce. Wyłączanie cors ma tylko sens przy jakiś developerskich testach. Ciężko mi sobie wyobrazić sytuacje by prosić użytkowników o wyłączenie CORS bo coś nie działa :P
Nie powiedziales o najwazniejszym. Jak skoro to bekend wysyla headery ale Ty nie mozesz odpytac bekendu to skad je bierzesz? Warto byloby wspomniec o OPTIONS
Dlaczego gdy ustawiasz jednego origina i credentials na true to zapytanie działa, po czym zmieniasz origina na * , wówczas credentials powoduje błąd (to wyjaśniłeś, dziękuję), po czym ponownie ustawiasz konkretnego origina i ustawiasz credentials na true i już nie działa? cos koło 4:30 ;)
W 4:36 wyłączyłem (przez zakomentowanie) header "Allow Credentials" po czym zrobiłem testowe zapytanie z credentials: true. Spowodowało to wyrzucenie błędu. To było zamierzone. Dzieje się tak ponieważ CORS pozwala nam nie tylko na kontrolę które originy są dozwolne, ale właśnie też sposobem w jakim te originy mogą się komunikować. Czasami ze względów bezpieczeństwa zabrania się komunikacji z określonymi headerami lub właśnie bez credentials: true
Generalnie tak, ale trzeba to trochę uściślić. Przeglądarka nie eliminuje Ci całkowicie ryzyka CSRF. Jak komuś uda się zforgować zapytanie HTTP na ten sam origin to przeglądarka nie pomoże (np przy podatności XSS w Twojej apce). Warto więc też dodatkowo stosować tokeny CSRF w formularzach. Przeglądarka eliminuje ryzyko CSRF do obcego/innego originu jeżeli ten jest prawidłowo skonfigurowany.
zauważyłem, że błąd cors'ow jest pomiędzy frontend-backend lub frontend-frontend. A jeśli jest zapytanie backend-backend to corsy wtedy nie działają, czy jak? I wtedy nawet jak jest podany Allow Origin (inny niż nasz backend oczywiście) to zapytanie nadal jest zezwalane/wykonywane ;/
CORS działa tylko w przeglądarce, w momencie gdy mamy zapytanie między jednym originem a drugim. Dlaczego tylko w przeglądarce? Bo przeglądarka ma mechanizm który sprawdza nagłówki cors. Jak masz zapytanie backend- backend albo korzystasz z CURL to tam to nie jest w żaden sposób sprawdzane 🙂
Docker nie ma tutaj nic do rzeczy 🙂 W dockerze możesz odpalić kontener z aplikacja backendowa np nodejs albo django i tam konfigurujesz kwestie związane z cors
Czy da się rozwiązać problem z zewnętrznym API które ma "źle" ustawionego CORSa w wersji produkcyjnej aplikacji? Dodatek do przeglądarki średnio jest rozwiązaniem w takiej sytuacji.
@@IpatrykPl oczywiście też można tak zrobić, ale traktowałbym to naprawdę jako ostateczność. Nie spotkałem się jeszcze z sytuacją aby nie dało się ustawić corsow i dogadać z innym zespołem / klientem by to skonfigurowali. Proxy to dodatkowy element którym musisz zarządzać (maintenance, monitoring, aktualizacja, ujęcie w procesie deploya). Lepiej sobie nie dokładać takich zmartwień 🙂
Film jest długi a CORS to w zasadzie prosty mechanizm. Dzięki CORS możemy wykonywać zapytania z innego ORIGIN’A na serwer http. W tym celu stosujemy header Acess-Control-Allow-Origin: origin=adress URL z którego się możemy się łączyć z serwerem http (przez API) / * (wildcard) akceptuje zapytania ze wszystkich originów
Trochę nie do końca się zgadzam z definicją CORS. każda przeglądarka blokuje zapytania między różnymi origin, a CORS właśnie umożliwia dzielenie się tymi zasobami a nie blokuje te zasoby. Blokowanie jest w każdej przeglądarce od zawsze (od kiedy wszedł AJAX).
"Zobacz ty frontend deweloperze, tutaj wszystko działa..." leże na dechach ze śmiechu! życiowa sytuacja 🤣
Oj tak, wspomniałem o tym bo sam miałem parę identycznych sytuacji :D
miodzio materiał i już wiem jak laravela naprawić swojego ❤😂
Więcej takich krótkich materiałów na jeden temat!
WINCYJ takich krotkich acz tresciwych filmikow 😎
Jest to jedno z najczęściej zadawanych przeze mnie pytań rekrutacyjnych ;)
Dzięki Artur za proste wyjaśnienie :)
Dzięki za pomoc
Dzieki! extra materiał
Dzięki wielkie :)
Super :)
I wszystko jasne.
Wartościowy materiał to też komentarz dla zasięgów jest :D
Jak nie macie możliwości ustawienia corsów na backendzie możecie użyć servera proxy który symuluje/zastępuje odpowiedni adres ( w React to jedna linijka kodu)
Z tego co wiem takie rozwiązanie działa ale tylko na develop :c
fajne wyjaśnienie! 6:30 skoro można wyłączyć politykę cors w przeglądarce to po wyłączeniu można wykonywać już zapytania do innych originów? Jeżeli tak to po co ten cors skoro można go wyłączyć i łatwo go obejść?
Można samemu u siebie go wyłączyć, ale 99,9% użytkowników internetu i tak ma go domyślnie włączonego w przeglądarce. Wyłączanie cors ma tylko sens przy jakiś developerskich testach. Ciężko mi sobie wyobrazić sytuacje by prosić użytkowników o wyłączenie CORS bo coś nie działa :P
Nie powiedziales o najwazniejszym. Jak skoro to bekend wysyla headery ale Ty nie mozesz odpytac bekendu to skad je bierzesz? Warto byloby wspomniec o OPTIONS
Czy można się spodziewać filmu o credentials oraz http cookies?
Spróbuję coś zmonotować w wolnym czasie :)
Masz ode mnie subskrypcje, ale na przyszłość ograniczyłbym wstęp i "dowcipy", bo film zaczyna się od 1:00.
Popracuje nad dowcipami albo wstępami 😅
Dlaczego gdy ustawiasz jednego origina i credentials na true to zapytanie działa, po czym zmieniasz origina na * , wówczas credentials powoduje błąd (to wyjaśniłeś, dziękuję), po czym ponownie ustawiasz konkretnego origina i ustawiasz credentials na true i już nie działa? cos koło 4:30 ;)
W 4:36 wyłączyłem (przez zakomentowanie) header "Allow Credentials" po czym zrobiłem testowe zapytanie z credentials: true. Spowodowało to wyrzucenie błędu. To było zamierzone. Dzieje się tak ponieważ CORS pozwala nam nie tylko na kontrolę które originy są dozwolne, ale właśnie też sposobem w jakim te originy mogą się komunikować. Czasami ze względów bezpieczeństwa zabrania się komunikacji z określonymi headerami lub właśnie bez credentials: true
Czy dobrze rozumiem, że jeśli tylko backend nie 'zezwala wszystkim', to domyślne zachowanie przeglądarki eliminuje z automatu ryzyko CSRF?
Generalnie tak, ale trzeba to trochę uściślić. Przeglądarka nie eliminuje Ci całkowicie ryzyka CSRF. Jak komuś uda się zforgować zapytanie HTTP na ten sam origin to przeglądarka nie pomoże (np przy podatności XSS w Twojej apce). Warto więc też dodatkowo stosować tokeny CSRF w formularzach.
Przeglądarka eliminuje ryzyko CSRF do obcego/innego originu jeżeli ten jest prawidłowo skonfigurowany.
zauważyłem, że błąd cors'ow jest pomiędzy frontend-backend lub frontend-frontend. A jeśli jest zapytanie backend-backend to corsy wtedy nie działają, czy jak? I wtedy nawet jak jest podany Allow Origin (inny niż nasz backend oczywiście) to zapytanie nadal jest zezwalane/wykonywane ;/
CORS działa tylko w przeglądarce, w momencie gdy mamy zapytanie między jednym originem a drugim. Dlaczego tylko w przeglądarce? Bo przeglądarka ma mechanizm który sprawdza nagłówki cors. Jak masz zapytanie backend- backend albo korzystasz z CURL to tam to nie jest w żaden sposób sprawdzane 🙂
oj jak to mnie... ***. Na szczęście są skróty do chroma pozwalające to wyłączyć.. tzn uruchomić skrót bez Corsa
Czy Docker eliminuje takie problemy z defaultu?
Docker nie ma tutaj nic do rzeczy 🙂 W dockerze możesz odpalić kontener z aplikacja backendowa np nodejs albo django i tam konfigurujesz kwestie związane z cors
Czy da się rozwiązać problem z zewnętrznym API które ma "źle" ustawionego CORSa w wersji produkcyjnej aplikacji? Dodatek do przeglądarki średnio jest rozwiązaniem w takiej sytuacji.
Tylko po stronie API możesz to rozwiązać. Nie ma innej możliwości
Jest inna możliwość. Można zrobić proxy dla API zewnętrznego
@@IpatrykPl niby tak, tylko wydaje się to średnio produkcyjne rozwiązanie, chyba, że już naprawdę nie ma innej opcji to akurat o tym wiem.
@@IpatrykPl oczywiście też można tak zrobić, ale traktowałbym to naprawdę jako ostateczność. Nie spotkałem się jeszcze z sytuacją aby nie dało się ustawić corsow i dogadać z innym zespołem / klientem by to skonfigurowali. Proxy to dodatkowy element którym musisz zarządzać (maintenance, monitoring, aktualizacja, ujęcie w procesie deploya). Lepiej sobie nie dokładać takich zmartwień 🙂
@@ArturChmaro tak, masz rację. To ostateczność, ale czasami konieczność
Film jest długi a CORS to w zasadzie prosty mechanizm. Dzięki CORS możemy wykonywać zapytania z innego ORIGIN’A na serwer http. W tym celu stosujemy header Acess-Control-Allow-Origin: origin=adress URL z którego się możemy się łączyć z serwerem http (przez API) / * (wildcard) akceptuje zapytania ze wszystkich originów
developerką xD dajcie spokój z tą Waszą śmieszną poprawnością
Daleko mi do śmiesznej poprawności 😉