Добрый день.

Еще один банальный вопрос, но все же...



Т.е. никоим образом не фильтровать переменную, просто проверять in_array, и если все ок, то прямо так и инклудить?

Возможно, есть какие-нибудь подводные камни, спецсимволы, которые in_array не уловит и т.д.?

Это сообщение отредактировал(а) maxipub - 28.7.2014, 17:05

in_array будет равен простому сравнению (==) между всеми значениями массива с группировкой по или (||). Максимум что можно добавить - это тождественное сравнение (===), путем задания третьего аргумента согласно документации.
В итоге получаем что безопасности ничего не угрожает в данном коде.

Хотя я лично такой код не принял бы на ревью, предложив хотя бы такой вариант:

Aliance, спасибо огромное, особенно за неточное сравнение!  

ЗЫ: а для общего развития, не могли бы подсказать, почему switch? Там ведь только неточное. Да и в in_array массив можно передавать переменной (из конфига или в некую функцию), вроде бы гибче и лаконичней?  

А я бы написал вот так, хотя вопрос не в этом.


после того, как узнал о существовании функции filter_input уже не могу её не применять

ndbn, а что именно filter_input выполняет в вашем примере?

Вообще, не хочется разводить флуд, но какое-то странное решение... file_exists + require_once как минимум  

И вообще, в моем конкретном случае суть не в валидации данных, а в возможности как раз упустить ее, если in_array (как мы уже выяснили) корректно будет принимать что угодно. Ведь конкретное множество доступных значений строго определено.

а я его люблю, он нагляднее  а точное в данном случае не сильно важно, потому что в любом случае мы ожидаем строку, строка же и будет приходить всегда. но даже если бы это было не так - можно было бы воспользоваться приведением к нужному типу в теле switch


а вот с этой точки зрения вы правы, просто в исходном примере ни слова о конфиге не было, поэтому я предложил свою альтернативу.

maxipub, 

Вырежет служебные символы, если не указывать третий параметр, то по-умолчанию он равен FILTER_DEFAULT или FILTER_UNSAFE_RAW.


Процитирую справку



Всякое бывает, маловероятно, но вполне реально, что обнаружится баг, например "при передаче в первом параметре функции in_array байта 0x02 она всегда возвращает TRUE"(повторюсь, это для примера). Я считаю, что лучше перебдеть.

Так в том то и дело! Когда программист использует require, подразумевается что без данного инклуда продолжение выполнение скрипта недопустимо. Вы же своей конструкцией require превратили зачем-то в include.  


А для filter_input значит это не "вполне реально"?  Не вижу разницы.

Лишнее обращение к файловой системе (по дефолту). Стараюсь не использовать без крайней надобности.

если обнаружится баг в программе (или тем паче в исполняемой системе), нужно от него избавляться, конкретно. а попытка учесть возможные баги...  


  

maxipub, имхо и так все достаточно безопасно, но уж если подходить параноидально, то единственная потенциальная проблема (в реальности её нет) - подстановка другого файла, использование относительного пути и тп штучки. filter тут бесполезен.
для устранения паранойййи надо обеспечить формирование пути на основе эталонного массива, а не внешних данных, т.е.


Это сообщение отредактировал(а) baldina - 30.7.2014, 22:31

Моя конструкция лишь позволяет предотвратить вываливание ошибки пользователю. Даже если пользователь передал правильное имя файла, сам файл может отсутствовать по тем или иным причинам и заметить это в большом проекте может быть достаточно затруднительно.
В include я ничего не превращал, разница между require и include в том, что второй генерирует warning, тем не менее не вижу смысла выводить его конечному пользователю.


Да, баг может быть где угодно, зачем пристегиваться в автомобиле, если в случае ДТП всё равно есть шанс умереть 



ИМХО, прием части имени подключаемого php файла от пользователя как раз такая крайняя необходимость.


У вас виден большой опыт в разработке больших проектов.

Ладно, срачу не быть 

Ну так в первом посте in_array не катит разве?

Ладно, всем спасибо, вопрос решен.