Ну я ж об этом и говорю — надо. Надо указывать контекст.
Но нам важно, чтобы даже и без указания контекста, выводимая переменная если уж не принесла пользы — то хотя бы не навредила. Я об этом выше и говорил. С тем, что надо указывать контекст, никто не спорит.
Я тупанул выше.
В «шаблонизаторах» мы как раз имеем inline-форматирование, когда фильтр накладывается уже перед самым выводом, и прописывается прямо в шаблоне. Так что да — в этом смысле шаблонизатор удобнее нейтива — о чем я и говорил, начиная эту ветку.
Но проблема с «конями», ей-богу — не самая большая у нейтива. Наложить фильтр эксплицитно — не проблема. Главная проблема — всё-таки, накладывание дефолтного фильтра.
Ну вот, к сожалению, в HTML я не очень силён, моя идея происходит от обработки параметров в SQL, где это работает 100%.
Но вообще, если говорить о выводе в HTML, то если любые спецсимволы конвертировать в HTML-сущности, то проблемы близости к оригиналу быть не должно, вроде бы.
Не понял, при чем здесь противопоставление «нейтив — шаблонизаторы».
Очевидно же, что разговор здесь идет о шаблонизаторах вообще, любых.
Все описанные выше принципы относятся к «шаблонизаторам» в той же самой мере. В них точно так же должна быть поддержка фильтров, которая должна иметь ту или иную внутреннюю реализацию. Вот варианты реализации фильтров мы и обсуждаем здесь.
На момент вызова tmpl::set() мы вообще не знаем, какой конкретно синтаксис в шаблонизаторе используется — нейтив или самопал. И не должны знать, по-хорошему.
Ну, это уже вкусовщина. У кого-то от угловых рябит, у кого-то — от фигурных.
А по поводу остальных фич — надо различать РНР как язык разметки шаблонов и Шаблонизатор как модуль приложения. Чистый PHP не означает «чисто include()» как обработчик шаблонов — такой обработчик все равно пишется специально. и в нем уже можно реализовать и наследование и многие другие вкусности
Я думаю, в хорошем приложении наборов должно быть больше.
«неэскейпенные» — это, на самом деле, частный случай, один из фильтров.
Но фильтров может быть много — urlencode, JSON к примеру.
Выхд-выход.
Это то, о чем я говорил выше. Безопасность важнее функциональности.
Всё правильно — выше описана, в сущности, идеальная модель разработки:
— по умолчанию всё форматируем наиболее безопасным способом
— для отличного контекста специально выставляем соответствующий контексту фильтр
— если разработчик зевнул и не выставил, то вывод бьётся
— не беда — когда разработчик это замечает, то просто добавляет соответствующий фильтр
Ну, на моей памяти из недавнего — например, об особенностях работы mysqli_multi_query(). Документация очень невнятная а результаты собственных экспериментов очень легко мисинтрпретировать.
Или вот я ещё спрашивал про удивительный баг — все функции для работы с файлами как одна молча отказывались работать с HTTP враппером. Ответ, правда, я получил уже после того, как написал воркараунд, но тем не менее.
После ФБ не было бешеного роста. Вот характерная картинка — www.google.ru/trends/explore#q=%2Fm%2F060kv
Она, хоть, и в собственных гуглопопугаях, но тренд совершенно очевиден.
Взрывной рост интереса к ПХП начался в начале века, когда он занял абсолютно пустую нишу, да ещё и предложил нулевой порог вхождения. Но уже к середине первой декады пошел на спад. А в середине второй, я, как активный участник многих ПХП-сообществ, невооруженным глазом вижу снижение интереса и трафика.
Фреймворки развиваются на фоне падения популярности.
Новичок читает статьи типа этвудовской «The PHP Singularity» с двойным гвоздодёром на картинке и выбирает что помоднее. Благо, выбор у него есть.
Бангалорские неприкасаемые не пишут энтерпрайз. Они побираются на одеске за еду. И, сколько в них денег ни влей, «Войну и мир» они не напечатают, увы
А организатор бизнес-процессов тоже анализирует тренды и выбирает наиболее, на его взгляд, перспективные.
Вокруг Друпала и Уордпресса уже сложились эффективные экосистемы, в которых 99% пользователей устраивает базовый функционал, а запросы остальных удовлетворяет имеющееся сообщество разработчиков — и особого прорыва с той стороны не видно.
В общем, падение популярности РНР в последние годы — это факт. И фреймворки — это действительно второе дыхание языка.
Вот — это очень дельный комментарий.
В отличие от SQL, в котором неверное форматирование не приведет к проблемам в безопасности, а, в худшем случае — просто к ошибке приложения, в HTML не так всё просто.
Я так думаю, что для дефолтного искейпинга надо применять более расширенный набор символов, чем тот, который используется в htmlspecialchars().
Ну это-то как раз просто.
Переменные в шаблон в любом случае должны передаваться какой-нибудь tmpl::set() — и вот у этой функции должен быть дополнительный параметр, который, скажем, делает переменную свойством специального объекта, или помещает в отдельный список — способов много.
Ну, я писал выше — в современных объектах далеко не все свойства доступны через public переменные, которые можно вытянуть через get_object_vars().
Всякий lazy loading, getters и прочая магия сильно затрудняют такой прямолинейный подход.
К тому же, возвращать данные может не только свойство, но и метод.
Но сам по себе подход хорош. Я пытался решить задачу таким же примерно наскоком, но обломался, по причинам, изложенным выше.
И вообще, очень приятно видеть ответы с кодом. Очень люблю такой подход!
Речь идет о событиях, которые просходят уже после описываемых.
Интерес к РНР в мире стабильно падает уже несколько лет, и никакой ФБ этому не помеха.
Сообщества закрываются, трафик на ресурсах падает. На Хабре частота статей по пхп упала в несколько раз. На Стаковерфлоу, скажем, бешеный трафик поддерживается исключительно за счет бангалорских бедняков, для которых писать на пхп — это альтернатива ручной разборке океанских лайнеров на металлолом. И пхп там — исключительно процедурная лапша из прошлого века (которая, кстати, на мой взгляд, и есть главный двигатель популярности). И в начале статьи упоминается именно этот факт.
Так что важность фреймворков, действительно, проявляется не где-то в истории, а прямо сейчас.
Должен-должен.
Это как в SQL — по умолчанию все передаваемые данные обрабатываются как строки. Любые исключения надо оговаривать специально. Иначе проблем не избежать
Это очень скоропалительный комментарий, не проходит проверку практикой.
Как раз в PHP, как языке общего назначения, так делать ни в коем случае нельзя.
Ведь проблема касается только одной ипостаси, РНР-как-шаблонизатора.
правда, для <?=?> оно с одной стороны, идеально подходит, но с другой — настолько ломать обратную совместимость — я думаю, невозможно.
Беда в том, что как раз в приведённом выше примере мы имеем объект $order, и это очень показательно.
А объекты — штука тонкая. К моменту попытки автоискейпинга объект может ещё не знать, что у него такое свойство есть.
Или вообще его не иметь.
Ну то есть да — если заставить разработчика передавать в шаблон только скаляры и массивы — это работает.
Но, увы, я еще не встречал ни одного, который бы не хотел передать в шаблон объект $user и уже в шаблоне обращаться к его свойствам/методам. Хотя сам считаю это порочной практикой.
Ну вот это «очень легко решается» и проблема.
Кто-то стал решать, но не зная технологии, насовал в _e() кучу бесполензного мусора.
Кто-то вообще не знал, что что-то решать надо.
Кто-то знал, да забыл.
В общем — типичный «пхп-стайл», и типичный же результат, ЕВПОЧЯ.
Я не зря привел аналогию с SQL — там эти баталии на тему «легко решается» уже (надеюсь) отгремели, и все согласились наконец-то, что ручное экранирование должно быть забыто как страшный сон.
Ну вот кстати это тоже неправильно. Автоэкранирование должно быть в дефолтном операторе, а всё остальное — опция.
то есть, всё должно быть наоборот — в Laravel пишем {{{ }}} по дефолту, а можно написать {{ }}, если надо вывести данные как есть. А вообще определять вывод количеством скобочек — это мина замедленного действия
Эта ерунда с подсчетом скобочек еще аукнется многочисленными XSS-ами.
Чем я сейчас и занимаюсь. Это ж ведь не языком чесать — тут время нужно :)
Но нам важно, чтобы даже и без указания контекста, выводимая переменная если уж не принесла пользы — то хотя бы не навредила. Я об этом выше и говорил. С тем, что надо указывать контекст, никто не спорит.
В «шаблонизаторах» мы как раз имеем inline-форматирование, когда фильтр накладывается уже перед самым выводом, и прописывается прямо в шаблоне. Так что да — в этом смысле шаблонизатор удобнее нейтива — о чем я и говорил, начиная эту ветку.
Но проблема с «конями», ей-богу — не самая большая у нейтива. Наложить фильтр эксплицитно — не проблема. Главная проблема — всё-таки, накладывание дефолтного фильтра.
Но вообще, если говорить о выводе в HTML, то если любые спецсимволы конвертировать в HTML-сущности, то проблемы близости к оригиналу быть не должно, вроде бы.
Очевидно же, что разговор здесь идет о шаблонизаторах вообще, любых.
Все описанные выше принципы относятся к «шаблонизаторам» в той же самой мере. В них точно так же должна быть поддержка фильтров, которая должна иметь ту или иную внутреннюю реализацию. Вот варианты реализации фильтров мы и обсуждаем здесь.
На момент вызова tmpl::set() мы вообще не знаем, какой конкретно синтаксис в шаблонизаторе используется — нейтив или самопал. И не должны знать, по-хорошему.
А по поводу остальных фич — надо различать РНР как язык разметки шаблонов и Шаблонизатор как модуль приложения. Чистый PHP не означает «чисто include()» как обработчик шаблонов — такой обработчик все равно пишется специально. и в нем уже можно реализовать и наследование и многие другие вкусности
«неэскейпенные» — это, на самом деле, частный случай, один из фильтров.
Но фильтров может быть много — urlencode, JSON к примеру.
Это то, о чем я говорил выше. Безопасность важнее функциональности.
Всё правильно — выше описана, в сущности, идеальная модель разработки:
— по умолчанию всё форматируем наиболее безопасным способом
— для отличного контекста специально выставляем соответствующий контексту фильтр
— если разработчик зевнул и не выставил, то вывод бьётся
— не беда — когда разработчик это замечает, то просто добавляет соответствующий фильтр
Или вот я ещё спрашивал про удивительный баг — все функции для работы с файлами как одна молча отказывались работать с HTTP враппером. Ответ, правда, я получил уже после того, как написал воркараунд, но тем не менее.
После ФБ не было бешеного роста. Вот характерная картинка — www.google.ru/trends/explore#q=%2Fm%2F060kv
Она, хоть, и в собственных гуглопопугаях, но тренд совершенно очевиден.
Взрывной рост интереса к ПХП начался в начале века, когда он занял абсолютно пустую нишу, да ещё и предложил нулевой порог вхождения. Но уже к середине первой декады пошел на спад. А в середине второй, я, как активный участник многих ПХП-сообществ, невооруженным глазом вижу снижение интереса и трафика.
Фреймворки развиваются на фоне падения популярности.
Новичок читает статьи типа этвудовской «The PHP Singularity» с двойным гвоздодёром на картинке и выбирает что помоднее. Благо, выбор у него есть.
Бангалорские неприкасаемые не пишут энтерпрайз. Они побираются на одеске за еду. И, сколько в них денег ни влей, «Войну и мир» они не напечатают, увы
А организатор бизнес-процессов тоже анализирует тренды и выбирает наиболее, на его взгляд, перспективные.
Вокруг Друпала и Уордпресса уже сложились эффективные экосистемы, в которых 99% пользователей устраивает базовый функционал, а запросы остальных удовлетворяет имеющееся сообщество разработчиков — и особого прорыва с той стороны не видно.
В общем, падение популярности РНР в последние годы — это факт. И фреймворки — это действительно второе дыхание языка.
В отличие от SQL, в котором неверное форматирование не приведет к проблемам в безопасности, а, в худшем случае — просто к ошибке приложения, в HTML не так всё просто.
Я так думаю, что для дефолтного искейпинга надо применять более расширенный набор символов, чем тот, который используется в htmlspecialchars().
Переменные в шаблон в любом случае должны передаваться какой-нибудь tmpl::set() — и вот у этой функции должен быть дополнительный параметр, который, скажем, делает переменную свойством специального объекта, или помещает в отдельный список — способов много.
Всякий lazy loading, getters и прочая магия сильно затрудняют такой прямолинейный подход.
К тому же, возвращать данные может не только свойство, но и метод.
Но сам по себе подход хорош. Я пытался решить задачу таким же примерно наскоком, но обломался, по причинам, изложенным выше.
И вообще, очень приятно видеть ответы с кодом. Очень люблю такой подход!
Интерес к РНР в мире стабильно падает уже несколько лет, и никакой ФБ этому не помеха.
Сообщества закрываются, трафик на ресурсах падает. На Хабре частота статей по пхп упала в несколько раз. На Стаковерфлоу, скажем, бешеный трафик поддерживается исключительно за счет бангалорских бедняков, для которых писать на пхп — это альтернатива ручной разборке океанских лайнеров на металлолом. И пхп там — исключительно процедурная лапша из прошлого века (которая, кстати, на мой взгляд, и есть главный двигатель популярности). И в начале статьи упоминается именно этот факт.
Так что важность фреймворков, действительно, проявляется не где-то в истории, а прямо сейчас.
Это как в SQL — по умолчанию все передаваемые данные обрабатываются как строки. Любые исключения надо оговаривать специально. Иначе проблем не избежать
Как раз в PHP, как языке общего назначения, так делать ни в коем случае нельзя.
Ведь проблема касается только одной ипостаси, РНР-как-шаблонизатора.
правда, для <?=?> оно с одной стороны, идеально подходит, но с другой — настолько ломать обратную совместимость — я думаю, невозможно.
А объекты — штука тонкая. К моменту попытки автоискейпинга объект может ещё не знать, что у него такое свойство есть.
Или вообще его не иметь.
Ну то есть да — если заставить разработчика передавать в шаблон только скаляры и массивы — это работает.
Но, увы, я еще не встречал ни одного, который бы не хотел передать в шаблон объект $user и уже в шаблоне обращаться к его свойствам/методам. Хотя сам считаю это порочной практикой.
Кто-то стал решать, но не зная технологии, насовал в _e() кучу бесполензного мусора.
Кто-то вообще не знал, что что-то решать надо.
Кто-то знал, да забыл.
В общем — типичный «пхп-стайл», и типичный же результат, ЕВПОЧЯ.
Я не зря привел аналогию с SQL — там эти баталии на тему «легко решается» уже (надеюсь) отгремели, и все согласились наконец-то, что ручное экранирование должно быть забыто как страшный сон.
то есть, всё должно быть наоборот — в Laravel пишем {{{ }}} по дефолту, а можно написать {{ }}, если надо вывести данные как есть. А вообще определять вывод количеством скобочек — это мина замедленного действия
Эта ерунда с подсчетом скобочек еще аукнется многочисленными XSS-ами.