Dlaczego żądanie GET nie powinno zmieniać danych na serwerze?

W całym Internecie widzę następujące porady:

GET nigdy nie powinien zmieniać danych na serwerze - użyj do tego żądania POST

Jaka jest podstawa tego pomysłu?

Jeśli utworzę usługę php, która wstawi dane do bazy danych i przekażę jej parametry w ciągu zapytania GET, dlaczego tak się dzieje? (Używam przygotowanych instrukcji, aby zająć się SQL Injection). Czy żądanie POST jest w jakiś sposób bardziej bezpieczne?

Czy może ma to jakiś historyczny powód? Jeśli tak, to jak ważna jest dzisiaj ta rada?

To nie jest rada.

A GETjest zdefiniowane w ten sposób w protokole HTTP . Ma być idempotentny i bezpieczny .

Jeśli chodzi o to, dlaczego - a GETmożna buforować, a w przeglądarce odświeżono. Raz po raz po raz.

Oznacza to, że jeśli zrobisz to samo GETjeszcze raz, będzie wstawić do bazy danych ponownie .

Zastanów się, co to może znaczyć, jeśli GETstaje się linkiem i jest indeksowane przez wyszukiwarkę. Baza danych będzie pełna zduplikowanych danych.

Sugeruję również czytanie identyfikatorów URI, adresowalności oraz stosowanie HTTP GET i POST .

Występuje również problem z pobieraniem linków w niektórych przeglądarkach - będą one wywoływać pobieranie linków, nawet jeśli nie zostało to zaznaczone przez autora strony.

Jeśli, powiedzmy, twoje wylogowanie jest za „GET”, linkowanym z każdej strony w Twojej witrynie, ludzie mogą się wylogować właśnie z powodu tego zachowania.

Każdy czasownik HTTP ma swoją własną odpowiedzialność. Na przykład GETzgodnie z definicją RFC

oznacza pobranie dowolnej informacji (w formie encji) zidentyfikowanej przez URI żądania.

POSTz drugiej strony oznacza wstawkę lub bardziej formalnie

Metoda POST służy do żądania, aby serwer źródłowy zaakceptował
jednostkę zawartą w żądaniu jako nowego podwładnego zasobu
określonego przez identyfikator URI żądania w wierszu żądania

Powody, dla których warto to zachować:

• Jest to bardzo proste i działa w skali globalnej Internetu od 1991 roku
• Trzymaj się zasady pojedynczej odpowiedzialności
• Inne strony używają, GETaby działać jako środek wyszukiwania informacji i eksploracji danych
• Zakłada się, że GET jest bezpieczną operacją, która nigdy nie zmienia stanu zasobu
• Względy bezpieczeństwa GETsą w istocie odczytem , podczas gdy w POSTrzeczywistości stanowią zapis
• GET jest buforowany przez przeglądarki, węzły w sieci, dostawców usług internetowych
• O ile treść nie ulegnie zmianie, GETten sam adres URL musi zwrócić te same wyniki wszystkim użytkownikom, w przeciwnym razie nie będziesz mieć zaufania do zwracanego wyniku

Dla kompletności i tylko w celu wymuszenia prawidłowego użycia (źródło) :

• GETparametry są przekazywane jako część adresu URL, który domyślnie ma małą i ograniczoną długość 256 znaków, a niektóre serwery obsługują ponad 4000 znaków. Jeśli chcesz wstawić długi rekord, nie ma uzasadnionego sposobu na przekazanie tych danych
• Podczas korzystania z bezpiecznego połączenia, ̶ takim jak TLS, ̶ URL jest nie dostaję szyfrowane, ̶ stąd wszystkie parametry ̶ ̶G̶E̶T̶̶ są przesyłane jako zwykły tekst. Adres URL jest zaszyfrowany za pomocą TLS, więc TLS jest w porządku.
• Wstawianie danych binarnych lub znaków spoza ASCII GETjest niepraktyczne
• GET jest ponownie wykonywane, jeśli użytkownik naciśnie przycisk Wstecz w przeglądarce
• Niektóre starsze roboty mogą nie indeksować adresów URL ze ?znakiem wewnątrz

EDYCJA: Wcześniej powiedziałem, że POST pomaga chronić cię przed CSRF, ale to źle. Nie przemyślałem tego poprawnie. Musisz wymagać unikalnego ukrytego tokena o zasięgu sesji we wszystkich swoich żądaniach zmiany danych w celu ochrony przed CSRF.

Na początku Internetu istniały akceleratory przeglądarki. Programy te zaczną klikać łącza na stronie w celu buforowania zawartości. Google Web Accelerator był jednym z tych programów. Może to spowodować spustoszenie w aplikacji, która wprowadza zmiany po kliknięciu łącza. Zakładam, że nadal są ludzie używający oprogramowania przyspieszającego.

Serwery proxy i przeglądarki będą buforować żądania GET, więc gdy użytkownik ponownie wejdzie na stronę, może nie wysłać żądania do aplikacji, więc użytkownik myśli, że podjął działanie, ale tak naprawdę nie zrobił.

Jeśli utworzę usługę php, która wstawi dane do bazy danych i przekażę jej parametry w ciągu zapytania GET, dlaczego tak się dzieje?

Najprostsza odpowiedź brzmi: „bo to nie to GETznaczy”.

Przekazywanie GETdanych do aktualizacji jest jak pisanie listu miłosnego i wysyłanie go w kopercie z napisem „OFERTA SPECJALNA - DZIAŁAJ TERAZ!” W obu przypadkach nie powinieneś być zaskoczony, że odbiorca i / lub pośrednicy źle obchodzą się z Twoją wiadomością .

Do operacji CRUD w aplikacji zorientowanej na bazę danych użyj następującego schematu:

Użyj HTTP GET do operacji odczytu (SQL SELECT)

Użyj HTTP PUT do operacji aktualizacji (SQL UPDATE)

Użyj HTTP POST do tworzenia operacji (SQL INSERT)

Użyj HTTP DELETE dla operacji usuwania (SQL DELETE)

GET nigdy nie powinien zmieniać danych na serwerze - użyj do tego żądania POST

Ta rada i wszystkie odpowiedzi tutaj są błędne. Oczywiście jestem zbyt dramatyczny, inne odpowiedzi są doskonałe, ale uważam, że dokładna rada powinna być udzielona w następujący sposób:

GET rzadko powinien zmieniać dane na serwerze - użyj do tego żądania POST

Stwierdzenie, że „nigdy” nie jest zbyt ekstremalne, i chociaż inne odpowiedzi tutaj dokładnie wyjaśniają, dlaczego powinieneś „rzadko” to robić, istnieje kilka scenariuszy, w których zmiana danych za pomocą GET jest całkowicie uzasadniona. Przykładem jest jednorazowy link weryfikacyjny e-mail. Zazwyczaj łącza te zawierają identyfikator GUID, który po uzyskaniu dostępu będzie musiał zmienić dane. Jeśli poprawnie zaimplementowane kolejne identyczne żądania GET zostaną zignorowane.

Jest to oczywiście przypadek skrajny, ale z pewnością warty odnotowania.