Безпосередня модифікація суперглобалів

Я бачив, як люди (які зазвичай пишуть хороший код) безпосередньо змінюють $_POSTмасив таким кодом:

// 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.

update_record()Має сенс, що не слід отримувати доступ до $ _POST безпосередньо, тому ми можемо передавати до нього інші масиви даних, але, напевно, це ледачий, поганий дизайн чи, можливо, просто неправильний? Однак ми все ще передаємо дійсний масив update_record(), тож навіщо створювати новий?

Це не питання, а лише приклад використання. Однак я чув, як багато людей кажуть, що цього не слід робити з $_REQUESTданими, і це погана практика. Але чому? Виглядає досить нешкідливо.

Приклади:

• Встановлення значення за замовчуванням $_GET(або повідомлення), яке насправді не існує

• Додавання $_POSTзначень, які насправді не були розміщені після надсилання форми

• Безпосередньо дезінфікувати або фільтрувати $_GETзначення масивів або ключі дуже рано на сценарії (резервна санітарія ... чому б і ні?)

• Встановлення $_POSTзначення вручну перед подачею форми для заповнення вводу зі значенням за замовчуванням (коли вхід читає $_POSTйого за замовчуванням; я це зробив)

• Формування власних $_SERVERцінностей? Звичайно, ей, чому б і ні?

• Як щодо інших, як $_COOKIEі $_SESSION? Звичайно, ми маємо їх змінити прямо так? Тоді чому б не інші?

Чи не слід робити прямих модифікацій суперглобалів , чи це в деяких випадках нормально ?

Зважаючи на те, що PHP вже встановлює ці суперглобали, я не думаю, що це зло, щоб їх змінювати. У деяких випадках це може бути найкращий спосіб вирішити проблеми ... особливо, коли ви маєте справу з кодом третьої сторони, який ви не можете легко змінити. (Вони можуть використовувати $_GETбезпосередньо або припускати, що в ньому існує якийсь ключ $_SERVERтощо)

Однак, загалом кажучи, я думаю, що це погана практика, коли ви пишете власний код. Модифікація $_REQUESTданих за допомогою деякого фільтру за кадром, який працює на кожній сторінці автоматично, може призвести до побічних ефектів. (Дивіться всі проблеми, які "магічні цитати" викликали для доказу.)

Тож якщо ви цього не збираєтесь (автоматично фільтруйте суперглобали), то наступне не принесе жодних переваг:

$_POST['foo'] = filter($_POST['foo']);

коли ви можете просто зробити це:

$foo = filter($_POST['foo']);

Я думаю , що це набагато більш ясно , щоб зробити общесистемное відмінність , яке $_POSTі $_GETбуде завжди нефільтроване, ненадійні дані, і вони не повинні ніколи бути використаний як є.

Копіюючи відфільтроване значення в іншу змінну, ви заявляєте, що "я розумію, що я роблю ... Я відфільтрував цей вхід, і це безпечно для використання".

Я, як правило, пропоную вам не змінювати заздалегідь визначені суперглобали, щоб було зрозуміло, що таке санізовані дані, а що - необроблені / ненадійні дані.

Інші можуть припустити, що якщо ви очистите надглобали на початку циклу запитів, вам не потрібно буде турбуватися про них в іншому місці.

Я б завжди відповідав їм, коли вам це потрібно:

$id = (int)$_POST['id'];

або подібне.

З точки зору інших змінних , це хороша практика , щоб не писати на будь-який з $_GET, $_POST, $_REQUEST,$_SERVER або $_COOKIE. $_SESSIONоднак відрізняється тим, що вам часто хочеться записувати дані в сеанс, який зберігається в різних запитах сеансу.

Вам слід уникати цього. Можливо, якийсь час ви забули щось санітувати, тоді ви можете отримати небезпечні дані. Якщо ви скопіюєте дані в нову структуру під час санітарії

• Ви отримуєте лише те, що хочете / потребуєте, а не те, що $_POSTтеж є
• Ви, ймовірно, отримаєте помилку, якщо в новоствореному масиві відсутні деякі клавіші або він взагалі відсутній

Додаткові інші сценарії можуть припускати, що масив недоторканий і може реагувати цікаво.

Мені ніколи не подобалася ідея зміни суперглобалу, оскільки вона вводить в оману. Це швидкий гакітний спосіб зробити щось, що, швидше за все, буде кращим способом зробити.

Якщо ви зміните значення $_POST , наприклад, ви говорите, що програмне забезпечення отримало дані, які не зробили.

РЕАЛЬНА ПРОБЛЕМА

Існує реальна життєва ситуація, коли це стає великою проблемою:

Уявіть, що ви працюєте в команді. В ідеальному світі всі використовують один і той же синтаксис, але ми не живемо в ідеальному світі. Один розробник, Джон, любить отримувати доступ до опублікованих даних за допомогою $_POST. Він щось змінює у публікації:

$_POST['ranking'] = 2; // John has changed ranking from 1 to 2 for whatever reason

Тоді у вас є інший розробник, Кріс, який вважає за краще використовувати filter_inputдля доступу до введених даних (тобто GET, POST, SERVER, COOKIE), оскільки він захищає програмне забезпечення при обробці даних, до яких користувач може втручатися. У своїй частині програмного забезпечення йому потрібно отримати посадову вартість ranking. Його частина коду - ПІСЛЯ Джона.

$ranking = filter_input(INPUT_POST, 'ranking', FILTER_SANITIZE_NUMBER_INT);
// $ranking = 1

З наведеного вище прикладу, змінивши суперглобал, ви зламали PHP. Джон $_POST['ranking']з будь-якої причини встановив значення 2, але тепер Кріс отримав значення 1

Коли я не бачив іншого способу зробити це:

Я працював над проектом, який використовував wordpress як свій блог за балансиром навантаження AWS. Це змінює значення $_SERVER['remote_address']. У цьому випадку інший розробник не мав іншого вибору, як зробити наступне:

if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $parts = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    $_SERVER['REMOTE_ADDR'] = $parts[0];
}

Висновок

Майже напевно є кращий спосіб, ніж змінювати суперглобали

Я думаю, що справжнє питання тут: «навіщо вам змінювати тему?». Я не бачу вагомих причин для цього. Якщо вам потрібно очистити імпульс, ви можете скористатися локальною змінною ...

Якщо ви не будете досить коротким (скажімо, довжиною менше 50 рядків), зміна цих супер-глобальних лише ускладнить ваш код у підтримці та підкреслення.

До речі, вам не потрібно передавати $ _POST функції, оскільки це надглобальний масив, який може отримати доступ навіть у локальній області функції.

Після того як спочатку відповідав на це запитання, кажучи, що не повинно бути причин змінювати суперглобали, я редагую цю відповідь на прикладі часу, коли я вирішив.

Зараз я працюю над таблицею бази даних для перезапису URL-адрес, згідно з якою request стовпець спрямовує користувача до відповідного targetстовпця.

Наприклад, requestможе бути blog/title-hereі йогоtarget може бути blog.php?id=1.

Оскільки blog.phpочікує $_GETзмінних, і я не хочу змінювати їх header("Location:"), мені залишається робити щось подібне:

$uri    = explode('?', $uri_request)[0];
$params = explode('?', $uri_request)[1];
parse_str($params, $_GET);

Це створює $_GETмасив, що містить призначені параметри, переданіtarget стовпцем.

Зрештою, я б настійно радив не змінювати суперглобали, якщо вам цього абсолютно не доведеться .