Результат выполнения вашего кода. Обратите внимание на ключи, выделенные жирным.
А помимо прочего, у нас с вами один и тот же косяк Элементы, у которых нет uid считаются дублями и остается только один из них. Я подправил этот момент.
Они и должны. Ведь идёт удаление дублей. Кроме того, ничего не сказано, что ключи не должны быть не по порядку. А если это так нужно - применить array_values() к результату.
На оставшихся элементах ключи видоизменяются. Становятся равны uid.
Добавление
И, потом, если в исходном массиве содержатся указатели, то они при таком подходе тоже порушатся. Если не содержатся, то замена массива не критична.
Если воспользоваться оператором IN, то, выделив, например, два жанра - детектив и драма,- получим все драмы и все детективы. Мне же нужно чтобы были получены ТОЛЬКО фильмы двух жанров (детектив, драма)
Как бы мне это провернуть?
Если речь о том, что фильм может присутствовать в двух жанрах (детектив и драма) и при выборке дублируется, то GROUP BY в помощь.
SELECT FROM WHERE <условие>;
В условии нужно что-то типа id=$mass[0] and id=$mass[1] and.... and id=$mass[n]
где n неизвестно заранее
Помогите составить запрос плиз!
AND тут, действительно, превращает условие в бесполезное. Скорее тогда OR.
А для массива неизвестной длины можно поступить так:
Т.е.
1. каждый элемент массива заключаем в правильные кавычки.
2. превращаем массив в строку, где все значения разделены запятыми
3. используем полученную строку в условии IN
Итоговое условие с $in будет такого вида:
WHERE id IN ('какойто_id','другой-то_id','итд_id')
Добавление
Можно все $in заменить на $mass... Тогда исходный массив $mass превратится в итоге в строку и его же и будем использовать в условии запроса. Это если исходный массив в дальнейшем при выполнении скрипта не нужен.
Если кто то получил доступ к файловой системе сервера, то метаться уже поздно. Какой смысл вставлять код в компилированные шаблоны, которые будут перезаписаные после сброса кэша? Ведь на сервере наверняка, есть куча других php файлов.
Логично. Но суть в следующем. По идее на все можно поставить запрет на запись, а на кэш нельзя (ну по определению). Скажем, получил ты доступ к исполнению php кода через иньекцию, но все вокруг только для чтения. В таком случае изменить можно только кэш. Я так рассуждаю. Поправьте, если не прав.
Попутный вопрос. Средствами php, насколько я понимаю, атрибуты файлов менять можно. А при любых настройках? Просто если можно, то тогда в итоге, действительно, по большому счету все равно какие атрибуты стоят на файлах. И, действительно, проще искать варианты размещения shell в постоянных скриптах, а не в кэше.
Тут уже скорее если смогли скомпрометировать файлы кэша, то нужно искать имеющиеся уязвимости.
Вот эта фраза заставила меня переформулировать вопрос. Скорее, его нужно поставить так.
Хранить кэш в классах - это элегантно и быстро. Но хранить кэш в сериализованном каким-либо образом виде, вероятно, безопаснее. При этом при десериализации можно избежать запуска измененного кода, но, безусловно, потерять в производительности. Дак вот, если принять за условие, что TWIG или другой подобным образом работающий шаблонизатор сам не пропускает в кэш чужой код, но он попадает в кэш через другие дырки, то при сериализованных шаблонах появляется дополнительная защита, но падает, как я уже сказал скорость обработки. И вопрос в том стоит ли париться в этом случае или такая вставка кода, если она случилась, безусловно не будет отнесена на счет шаблонизатора.
Условно, не получим в итоге фразы, что это шаблонизатор виноват, потому что вот если бы он хранил кэш в сериализованном виде, то такого бы не произошло?
ну насколько я знаю тот же твиг работает по белому списку комманд. что это значит, сначала он парсит шаблон и саздает класс с тем же шаблоном, но только тем который уже распарсен и вместо {var} имеет echo $var (как то так). Тоесть если нехоршый человек имеет доступ к файловой системе, ему не составит труда изменить код в кеше, но шаблонизатор сам не пропустит код PHP в шаблоне. Поправьте если я не прав
Создает файл с классом. Имя класса - хэш имени шаблона (с солями и т.п.). При запуске не парсит, а ищет сначала нужный класс и проверяет время создания начального шаблона. Если время создания начального шаблона изменилось, то перепарсит, если кэша нет, то тоже.
Но суть не в этом. Можно же не в echo записать, а вообще вне класса.
Если кто-то посторонний имеет доступ к ФС - беспокоиться уже поздно. Гасить сервер и полный аудит, что откуда и как влезли.
Т.е. правильно я понимаю, что эту возможность надо отсекать на других уровнях кода, а за подобную реализацию кэша можно быть спокойным? Т.е. если кто-то в класс чего-то запихал, то косяк точно не в организации кэша подобным образом?
Шаблонизатор TWIG хранит кэш, создавая классы и записывая их в файлы. При загрузке шаблона, проверяет есть ли файл с классом, не устарел ли и т.п. Потом использует класс через автозагрузку.
Вот у меня назрел общий вопрос. А насколько это безопасно? Например, если в файл с классом затолкать код (вне класса), то при загрузке класса этот код выполнится. И если в случае с постоянно используемыми классами, насколько понимаю, можно на файлы с классами поставить запрет на запись, то с кэшем так поступить не получится.
Соответственно, повторюсь, насколько такой вариант организации кэша безопасен и стоит ли в этом направлении беспокоиться дальше?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 329
Элементы, у которых нет uid считаются дублями и остается только один из них. Я подправил этот момент.
