Widziałem ludzi (którzy zazwyczaj piszą dobry kod) bezpośrednio zmieniających $_POST
tablicę za pomocą takiego kodu:
// Add some value that wasn't actually posted
$_POST['last_activity'] = time();
// Alter an existing post value
$_POST['name'] = trim($_POST['name']);
// Our pretend function
// Pass the entire $_POST array as data to work with in the function
// The function update_record() will read only the values we actually need
update_record($_POST);
// ...That sure was easier than creating a new array
// with only the $_POST values we actually need.
Ma to sens, że update_record()
nie należy bezpośrednio uzyskiwać dostępu do $ _POST, więc możemy na przykład przekazać do niego inne tablice danych, ale z pewnością jest to leniwy, zły projekt, a może po prostu zły? Nadal jednak podajemy prawidłową tablicę update_record()
, więc po co tworzyć nową?
To nie jest sedno pytania, tylko przykład użycia. Słyszałem jednak, że wiele osób mówi, że nie należy tego robić z $_REQUEST
danymi, a to zła praktyka. Ale dlaczego? Wygląda wystarczająco nieszkodliwie.
Przykłady:
Ustawienie domyślnej
$_GET
(lub opublikowanej) wartości, która tak naprawdę nie istniejeDodawanie
$_POST
wartości, które nie zostały faktycznie opublikowane po przesłaniu formularzaBezpośrednie odkażanie lub filtrowanie
$_GET
wartości tablic lub kluczy na bardzo wczesnym etapie skryptu (awaryjne zabezpieczenia ... dlaczego nie?)$_POST
Ręczne ustawianie wartości przed przesłaniem formularza w celu wypełnienia danych wejściowych wartością domyślną (gdy dane wejściowe odczytują$_POST
wartość domyślną; zrobiłem to)Tworzysz własne
$_SERVER
wartości? Jasne, hej czemu nie?A co z innymi, jak
$_COOKIE
i$_SESSION
? Oczywiście musimy modyfikować te bezpośrednio, prawda? Więc dlaczego nie inni?
Czy bezpośrednia modyfikacja superglobali nigdy nie powinna być wykonywana, czy też jest w niektórych przypadkach w porządku ?
Odpowiedzi:
Biorąc pod uwagę, że PHP już ustawia te superglobale, nie sądzę, że modyfikowanie ich jest złe . W niektórych przypadkach może to być najlepszy sposób rozwiązywania problemów ... szczególnie w przypadku kodu innej firmy, którego nie można łatwo zmodyfikować. (Mogą używać
$_GET
bezpośrednio lub zakładać, że istnieje jakiś klucz$_SERVER
itp.)Jednak ogólnie mówiąc, myślę, że jest to zła praktyka, gdy piszesz swój własny kod. Modyfikowanie
$_REQUEST
danych za pomocą filtra „za kulisami”, który jest automatycznie uruchamiany na każdej stronie, może spowodować skutki uboczne. (Zobacz wszystkie problemy spowodowane przez „magiczne cytaty” na dowód).Więc jeśli nie zamierzasz tego robić (automatycznie filtrować superglobale), to następujące nie daje żadnych korzyści:
kiedy możesz łatwo zrobić:
Myślę, że to znacznie bardziej jasne wprowadzić rozróżnienie site-wide że
$_POST
i$_GET
są zawsze niefiltrowane, niezaufane dane, a oni powinni nigdy być używane jak jest.Kopiując odfiltrowaną wartość do innej zmiennej, twierdzisz: „Rozumiem, co robię ... Przefiltrowałem te dane wejściowe i można z nich bezpiecznie korzystać”.
źródło
$_POST
, odkażając w miarę postępów. A jeśli chodzi o innych ludzi, którzy to robią ... cóż, wiele osób pisze bardzo zły kod PHP, ale to też nie jest dla ciebie wymówką. :)Zasadniczo sugerowałbym, aby nie modyfikować predefiniowanych superglobali, aby było jasne, co to są oczyszczone dane, a co surowe / niezaufane dane.
Inni mogą sugerować, że jeśli posprzątasz superglobale na początku cyklu żądania, nie musisz się o nie martwić gdzie indziej.
Zawsze dopasowuję je, kiedy ich potrzebujesz:
lub podobne.
Pod względem pozostałych zmiennych jest to dobra praktyka, aby nie pisać do każdego z
$_GET
,$_POST
,$_REQUEST
,$_SERVER
lub$_COOKIE
.$_SESSION
jest jednak inny, ponieważ często chcesz zapisywać dane w sesji, które następnie są utrwalane dla różnych żądań w sesji.źródło
setcookie
istnieje, ale otrzymujemy pliki cookie$_COOKIE
? Ponadto, ponieważ$_COOKIE
jest ustawiany tylko w momencie rozpoczęcia bieżącej sesji i nigdy nie jest aktualizowany, wymaga zmiany / ustawienia plików cookie w obu obszarach, aby późniejsze obszary kodu miały aktualne informacje.Powinieneś tego unikać. Może kiedyś zapomniałeś coś odkażać, a potem możesz odzyskać niebezpieczne dane. Jeśli skopiujesz dane do nowej struktury podczas dezynfekcji
$_POST
środkuDodatkowe inne skrypty mogą zakładać, że tablica jest nietknięta i może reagować z ciekawością.
źródło
Nigdy nie podobał mi się pomysł modyfikowania superglobalu, ponieważ wprowadza w błąd. Jest to szybki, zuchwały sposób na zrobienie czegoś, co prawdopodobnie będzie lepszym sposobem.
Jeśli zmienisz
$_POST
na przykład wartość, oznacza to, że oprogramowanie otrzymało dane, których nie otrzymało.PRAWDZIWY PROBLEM
W rzeczywistej sytuacji staje się to dużym problemem:
Wyobraź sobie, że pracujesz w zespole. W idealnym świecie wszyscy używają tej samej składni, ale nie żyjemy w idealnym świecie. Jeden programista, John, lubi uzyskiwać dostęp do opublikowanych danych za pomocą
$_POST
. Zmienia coś w post varsach:Następnie masz innego programistę, Chris, który woli korzystać
filter_input
z dostępu do wprowadzonych danych (tj. GET, POST, SERVER, COOKIE), ponieważ zapewnia ochronę oprogramowania podczas przetwarzania danych, z którymi użytkownik może manipulować. W swojej części oprogramowania musi uzyskać wartość końcowąranking
. Jego część kodu to PO napisie Johna.Z powyższego przykładu, zmieniając superglobal, złamałeś PHP. John ustawił wartość
$_POST['ranking']
na 2 z dowolnego powodu, ale teraz Chris otrzymał wartość 1Gdy nie widziałem innego sposobu:
Pracowałem nad projektem, który wykorzystywał wordpress jako swojego bloga za równoważeniem obciążenia AWS. To zmienia wartość
$_SERVER['remote_address']
. W tym przypadku inny programista nie miał innego wyboru, jak tylko wykonać następujące czynności:Wniosek
Jest prawie na pewno lepszy sposób niż zmiana superglobali
źródło
Myślę, że prawdziwe pytanie brzmi „dlaczego powinieneś modyfikować motyw?”. Nie widzę żadnego ważnego powodu, aby to zrobić. Jeśli chcesz zdezynfekować imput, możesz użyć zmiennej lokalnej…
O ile kod nie jest wystarczająco krótki (powiedzmy, mniej niż 50 wierszy), modyfikacja tych superglobalnych tylko utrudniłaby utrzymanie i przechowywanie kodu.
Nawiasem mówiąc, nie musisz przekazywać $ _POST do funkcji, ponieważ jest to superglobalna tablica, do której można uzyskać dostęp nawet w lokalnym zakresie funkcji.
źródło
$_POST
dane? Przekazanie$_POST
powoduje, że funkcja odkaża wszelkie dane.Po wstępnej odpowiedzi na to pytanie stwierdzeniem, że nie powinno być powodu, aby modyfikować superglobale, edytuję tę odpowiedź na przykładzie, w którym postanowiłem.
Obecnie pracuję nad tabelą bazy danych przepisywania adresów URL, w której
request
kolumna kieruje użytkownika do odpowiedniejtarget
kolumny.Na przykład
request
może byćblog/title-here
itarget
może byćblog.php?id=1
.Ponieważ
blog.php
oczekuje$_GET
zmiennych i nie chcę tego zmieniaćheader("Location:")
, pozostaję robić coś takiego:Spowoduje to utworzenie
$_GET
tablicy zawierającej zamierzone parametry przekazane przeztarget
kolumnę.Ostatecznie zdecydowanie odradzam modyfikowanie superglobali, chyba że absolutnie musisz .
źródło