2012-06-19 11 views
6

Niedawno natknąłem tej linii w skrypcie PHP:

$_REQUEST['start_date']=$date; 

Czy wolno lub przydatne w żaden sposób przypisać coś do zmiennej $ _REQUEST Super globalnej? Jeśli istnieje $ _COOKIE ['start_data'], czy zmieni to wartość cookie?

+0

Tak, przydział jest całkowicie ważny, ale nie mogę znaleźć jego zastosowania – gopi1410

+2

Dlaczego nie spróbować i zobaczyć, co się stanie? W ten sposób uczysz się kodować. – vascowhite

+0

Możesz to zrobić tak. Nie wiesz, dlaczego? BTW. Możesz po prostu spróbować wykonać kod; P – Bono

Odpowiedz

6

Tak, jest dozwolone i może być pomocne z wielu powodów.

  • Debugowanie - Jeśli z jakiegoś powodu chcesz „siła” pewien parametr żądania, można ustawić wartość w $_REQUEST, $_GET lub $_POST tablic. To może przesłonić dowolną wartość wysłaną przez żądającą stronę, która może być pożądana.
  • Ponieważ masz zamiar coś zrobić z całą tablicę - jeśli chcesz, na przykład, json_encode wszystkich par $_REQUEST klucz-wartość, jak również w niektórych dodatkowych wartości, to może być szybsze, aby po prostu "dodać" wartości do $_REQUEST w ten sposób, a następnie przekazać $_REQUEST do json_encode().

Jeśli chodzi o pytanie dotyczące $_COOKIE, nie można zmienić wartości pliku cookie w ten sposób, tylko uzyskać do niego dostęp.

Uwaga od autora: Poniższy przykład został dodany jako sugerowana i zatwierdzona edycja do mojej oryginalnej odpowiedzi. Chociaż może się to udać, istnieją lepsze sposoby ochrony witryny przed atakami wtryskowymi (np. prepared statements). IMHO, rozważny programista powinien zdecydowanie rozważyć te podejścia, zanim powoła się na poniższy kod.

Pomyśl o zapobieganiu atakom SQL injection w Twojej witrynie. Ten prosty kod zatrzyma je dla wszystkich $_REQUEST zmiennych (mysqli przykład):

function injectionwall($dbinterface) 
{ 
    foreach($_REQUEST as $key => $data) 
    { 
     $_REQUEST[$key]=$dbinterface->real_escape_string($data); 
    } 
} 

Wszystkie zmienne $_REQUEST są teraz bezpieczne :)

+0

RE: "Uwaga od autora" - Masz prawo dodać to ostrzeżenie. Właściwie popieram usunięcie tego przykładu, ponieważ jest to BARDZO zła praktyka na tak wiele sposobów. Musi istnieć bezpieczniejszy przykład (chociaż staram się myśleć o przydatnym). – Robbie

0

Czy jest dozwolone lub przydatne w jakikolwiek sposób przypisanie czegoś do zmiennej $ 01REQUEST super ?

Tak, jest dozwolone, ale nieprzydatne.

Jeśli istnieje $ _COOKIE ['data_początkowa] to spowoduje zmianę wartości cookie?

Nie, korzystanie setcookie http://php.net/manual/en/function.setcookie.php

Wszystkie Ten super globalne zmienne tylko proste globalne tablice.

+4

Całkowicie nie zgadzam się ze stwierdzeniem, że "to nieprzydatne". – jedwards

+0

@jedwards Musi używać tej super zmiennej globalnej z ostrożnością, ponieważ może przepisać dane pierwotne, nie wiedząc o tym. Jeśli użyjesz tego U musisz wiedzieć jak to działa. Myślę, że nie zrobił " – Sergey

+0

Oprócz komentarza @jedwards, nie mogłeś użyć tej zmiennej do przechowywania czegoś na poziomie kontrolera i pobierania go na poziomie widoku (biorąc pod uwagę, że nadasz nazwę paramu całkiem" unikalną "nazwę, więc nie koliduje z czymś)? Wydaje się to całkiem dobrym przykładem tego, jak może być użyteczny, czy jestem w błędzie? – reallynice

3

myślę bardziej właściwą odpowiedź brzmi „Tak, to jest dozwolone, ale uważają to za złą praktykę, więc należy unikać lepszej jakości programowania ".

Dlaczego to wolno (i zapewne punktem swoje pytanie):

  • superglobals są ustawione na początku realizacji programu, a następnie w przeciwnym razie nie zmieniło (chyba to zrobić). Więc twoje zmiany są trwałe i łatwo widoczne w każdej innej funkcji. Więc śmiało, edytuj, jak chcesz.

Ale - dlaczego najlepiej unikać:

  • To ogólnie dobra praktyka, aby wiedzieć, jakie zmienne są i skąd pochodzą. Załóżmy, że masz funkcję, która "zabezpiecza" wszystkie twoje dane wejściowe, manipulując $ _REQUEST. Gdy użyjesz $ _REQUEST, nigdy nie będziesz mieć pewności, czy uruchomiłeś funkcję "make safe". Jeśli przeprowadzasz testy jednostkowe, staje się to szczególnie problematyczne. Jeśli ponownie przypisujesz $ _REQUEST do innej zmiennej, możesz łatwiej śledzić zakres tej zmiennej. Nawet jeśli uczynisz tę zmienną "globalną", to wiesz, że jest bezpieczna, istnieje. (Wadą może być marnowanie pamięci/mocy programowania w przypadku bardzo ciężkich aplikacji, ale daleko ci do tego, jeśli zadasz to pytanie.)

  • Jeśli zmodyfikujesz $ _REQUEST, NIE edytujesz $ _POST, $ _GET lub $ _COOKIE; może to prowadzić do nieporozumień, jeśli chcesz zmienić kod na $ _POST jako pewien czas w przyszłości (np. dane, które Twoim zdaniem "zrobiły bezpieczne" nie będą).

Wreszcie, dwa szybkie notatki na temat korzystania z $ _REQUEST w ogóle:

  • $ _REQUEST jest kombinacją $ _COOKIE, $ _POST i $ _GET (i $ _FILES w starszych wersjach). Ale nie wiesz, co będzie miało priorytet, chyba że przeczytasz plik php.ini - http://www.php.net/manual/en/ini.core.php#ini.variables-order. Więc nie polegaj na $ _POST, który ma wyższy priorytet niż $ _GET!

  • Kolejny powód użycia $ _POST, $ _GET lub $ _COOKIE, jeśli potrafisz: - Ułatwia przyszłym programistom debugowanie twojego kodu, ponieważ wiedzą, gdzie jest oczekiwana zmienna. Ale czasami jest to odpowiednie dla $ _REQUEST, jeśli naprawdę nie obchodzi cię, czy wartość pochodzi z pliku cookie, get lub post.

Nota prawna: tak, używam $ _REQUEST i tak, zmieniłem go, aby obejść kilka sytuacji. Mówię tylko nie, jeśli chcesz być lepszym programistą.

Powiązane problemy