Хотеть!
Иду, на этот раз — уже не один. :) В прошлый раз местами «зажгли» только так, понравилось. Главное — боевого настроя потом хватило надолго, вспыхнул интерес к изучению чего-то нового. Жаль только, что Фабьен Потенсьер отказался заехать.
За 5000 рублей можно было и что-то более серьёзное подготовить, имхо. На девконфе 2013 года практически ничего нового не узнал, хотя Laravel и архитектура игровых движков подкупают…
Не оценивайте мой отзыв как негативный. Сейчас ещё раз пересмотрел внимательно все доклады (прочитал описания на сайте), да, действительно есть довольно много интересного на что можно потратить такую сумму.
Это еще не все — пока подано 33-50% заявок. Многие докладчики еще думают, знают что уровень серьезный — и с халтурой заявка не пройдет :-)
Я помню как в прошлом году было выступление в PHP секции про sql инъекции, где 70% были советы откровенно для совсем начинающих, а остальные 30% — скорее как не надо делать. Скрещу пальцы, что бы в этом году подобного халатства не было =)
Это заблуждение, на самом деле.
Предубеждение вообще мешает воспринимать информацию адекватно, а в данном вопросе, где каждый школьник мнит себя экспертом — и подавно. Когда же доходит до дела — при написании чуть более сложных запросов, чем выборка по первичному ключу, или даже просто при обсуждении связанных вопросов — на свет вываливается фантастическая дремучесть таких «всезнаек». Что, в частности, неоднократно случалось при обсуждении темы здесь, на Хабре.
Заблуждение по поводу чего?
Весь час доклада мусолилось то, что на страницах интернета и так полным полно, а весь доклад можно сократить до одного предложения: «кастуйте данные к определённому типу». Что нового я узнал (и многоопытные коллеги с конференции) из этого? Главное то, что не было ни одного упоминания фильтров эктиврекорда и простого роутинга.

Я бы ещё мог понять, если бы рассказывали о безопасности в целом, о csrf токенах, о блокировки открытия сайта в айфреймах и прочем.

Для того, что бы не быть голословным, вот его доклад: 2013.devconf.ru/data/2013/presentation/24.pdf
Вы слушали какой-то другой доклад, а собирались на ещё какой-то, отличный от этих двух :)
Во-первых, это был доклад про SQL-инъекции, поэтому было бы глупо ожидать услышать там про csrf.
Во-вторых, про кастинг там не было ничего. Я не представляю, как можно перепутать приведение типов и форматирование SQL литералов. Это разные вещи.
В-третьих, важно не только само форматирование, но и где и когда оно происходит. magic_quotes тоже «кастовали», но это был эпик фейл.
В-четвертых, если вы считаете, что «роутинг» имеет хоть какое-то отношение к защите от инъекций, то доклад однозначно был провальный, но не потому что в нем не говорилось правильных вещей, а потому что их не получилось донести. Но вина докладчика в этом только частичная — как я говорил выше, пробить скепсис всезнайства и предубеждения очень трудно.
В-пятых, «фильтры эктиврекорда» там вполне упоминались. Когда РСУБД использвется в качестве примитивного key-value storage, эти фильтры прекрасно работают. Но как только нам начинает требоваться реальный SQL, а не примитивный его субсет, фильтры оказываются бесполезны. Об о всех таких случаях, когда «информация, которой полно в интернете» не помогает, и говорилось в докладе.

При этом, увы, сама по себе подача была так себе, без огонька. И у «многоопытных коллег» вполне могли быть обоснованные претензии как к самой информации, так и к её подаче. Но чтобы их понять и пересказать, надо хоть немного разбираться в теме.

При этом никто из «многоопытных коллег» не предлложил до сих пор всеобъемлющего решения, которое бы работало и с «фильтрами эктиврекорда», и с SQL, и с методами квери-билдеров, обеспечивая защиту на всех уровнях.
Странная ситуация складывается — «все всё знают», но единого решения нет. Есть только надерганные из разных источников и зачастую противоречащие друг другу «рекомендации из интернета».
Возможно вы правы, возможно нет. В любом случае спорить не буду, т.к. это моё личное и от этого субъективное мнение.

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

И да, я считаю что грамотный роутинг — это как-минимум 50% защиты от любых инъекций, т.к. он и типы проверяет и валидность строки по регулярке (или псевдо-регулярке), а при ошибке просто отредиректит на 404.

Не понимаю что значит реальный SQL? Это SQL, где больше 255 символов? Или SQL, который невозможно воспроизвести билдерами?

З.Ы. Под кастингом я имел ввиду типизированные плейсхолдеры, не верно выразился.
Роутинг не имеет отношения к защите от инъекций. Никакого. Больше того — и не должен иметь. Просто исходя из формальной логики. 100%-ю защиту не обеспечит, значит, надо защищать другими средствами. А если мы их используем, то защита роутингом оказывается бессмысленной. Не говоря уже о том что сам роутинг может использовать БД. Это совершенно разные и непересекающиеся области. Тот, кто защищается от инъекций роутингом, будет сидеть в инъекциях по уши.
Защиту от инъекций путем фильтрации входных параметров мы уже проходили — это magic quotes. Не помогло.

Больше того — на первом же слайде в докладе написано, что защищаться вообще не надо. принимать какие-то специальные меры по защите не нужно. Надо просто работать с БД. Средствами для работы с БД, а не парсером УРЛов.

Про типизованные плейсхолдеры в интернете нет практически ничего. Получается, что заявление про «мусолилось то, что на страницах интернета и так полным полно» не соответствует действительности.

Реальный SQL — это в первую очередь тот, который не входит в стандартные методы ORM («фильтры эктиврекорда»). Во вторую — тот, который невозможно воспроизвести билдерами, да.
<irоny>Конечно роутинг не имеет никакого отношения к защите от sql инъекций… А то, что мы указали в адресе /books/:id, где id только числовой ([0-9]+) и потом получаем в контроллере модель с этим id — это так, баловство. Оно не защитит от того, что пользователь вместо числа введёт строку, да ведь?

А то, что на этапе проверки какой-нибудь почты мы добавляем к ней фильтр почты и при ошибке возвращаем сообщение об ошибке не гарантирует того, что почта это именно почта и сквозь фильтр у нас вполне может просочится DROP TABLE students;, это ведь так похоже на email адрес.

И главное, что ничего работать не будет, т.к. sql у нас невозможно сгенерировать билдером!</irоny>

Извините, но пока что не убедительно, т.к. приходилось работать и не с таким и пока никаких проблем не бывало.
У, как всё запущено. Вам с инъекциями ещё рано.
Вам логику надо учить, молодой человек. Формальную.
Ну, и читать ещё желательно научиться.

А доклад и вправду провальный. Если после него такая разруха в голове осталась — то действительно, это эпик фейл.

Мы говорим о конечном продукте, а не о прямом доступе к базе данных из консоли браузера — тут уж никакой роутинг не спасёт.
И не стоит хамить пожалуйста, даже столь завуалированно. Лучше доходчиво объясните почему следования двум правилам — отсечение внешних данных роутингом и проверка значений фильтрами не убережёт от sql-инъекций. Зачем городить огород из типизированных плейсхолдеров?
Вы ведь уже поняли, что спорите с автором того доклада?
Спорю потому, что мог упустить какую-то тонкость, например какие-либо невидимые юникод-последовательности, которые могут пройти сквозь регулярку вида [a-z]+@[a-z_\.]+\.[a-z] (это только пример) и натворить гадостей, а волшебные плейсхолдеры спасут от этого. Вроде я уже раз 10 это написал, но как таковых примеров ошибочной уверенности во всемирно принятой практике разработки (не включающей магические типизированные плейсхолдеры) — не увидел =(
Да дело-то ведь не в авторе. А в том что каша в голове. Всё буквально с ног на голову.
Ерунда с входной валидацией у него — это «всемирно принятая практика».
А на самом деле всемирно принятая практика (использование подготовленных выражений) — для него это «зачем городить огород».

Пожалуйста не надо приплетать ваши домыслы к моим словам, я написал то, что написал, а не то, что вы пытаетесь пропихнуть за моё мнение.

Написано то, что кастинг в плейсхолдерах — это идиотизм, не больше — ни меньше и про prepared statments ни одного слова. Учитывая то, что не было ни одного примера того, что кастинг спасает лучше, нежели приведённые мною трижды примеры — смею высказать мнение о том, что вы намеренно уклоняетесь от прямого ответа и просто решили потрепать языком.

За сим заканчиваю диалог, т.к. не вижу смысла далее выслушивать ваш сарказм и троллинг.
Ладно, так и быть, я попробую один раз.
Хотя заранее уверен, что не получится — уж больно случай запущенный.

Любая проверка входящих данных не имеет ни малейшего отношения к работе с БД.
Ну, то есть, в типичном похапе-стайл говнокоде, где «роутер» — это if (isset($_POST['submit'])), после которого данные сразу же пихаются в mysql_query — тут вполне возможно визуально проконтролировать, что попадающие в запрос данные были проверены некой кривой регуляркой. Но так, вообще-то, никто давно не пишет.

Ты и сам упомянул роутер — за язык тебя никто не тянул. Наличие же роутера предполагает наличие мало-мальски структурированного приложения. В котором слой работы с БД отделен от роутера многими другими слоями. И к моменту, когда надо исполнять запрос, код не имеет ни малейшего представления о том, откуда взялись данные — из роутера, из POST-а, из БД, из файла, из веб-сервиса стороннего. Больше того — ему это знать и НЕ НАДО. А вот программисту желательно понимать принцип разделения полномочий. Хотя, о чем это я? Программистов среди пользователей похапе — раз-два, и обчёлся.

Получается, чтобы учесть результаты проверки роутером, надо прицеплять к данным какую-то специальную бирочку, мол, «мы тут в роутере проверили, всё чисто — можно в запрос писать напрямую». Разумеется, это будет глупость несусветная. Это заберет ресурсов в сто раз больше, чем сэкономит, и на пустом месте усложнит систему.

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

Мировая же практика — для любых данных, независимо от их источника, использовать подготовленные выражения. Где вместо самих данных в запросе ставятся метки — плейсхолдеры. Если тебе не хватает ума понять принцип типизованных плейсхолдеров (повсеместно уже пол-века применяемый в функциях семейства printf()) — ничего страшного, пусть будут обычные. Типизация — это всего лишь возможность унифицировать работу с данными различных типов, не раздувая код, давая малограмотному разработчику единый инструмент для любых типов данных. Но внутри у там все равно лежит тот же самый принцип подготовленных выражений (впрочем, судя по твоему последнему каменту, ты даже не понимаешь, что плейсхолдер — это обязательный, ключевой элемент подготовленного выражения, без которого оно бесполезно).

И в итоге, написав «Зачем городить огород из [типизированных] плейсхолдеров?» — и тут же предложив взамен проверку входящих данных! — ты поставил всё с ног на голову — отрицая действительно общепринятую практику, и продвигая левый бессмысленный самопал.
В общем, я надеюсь что ты поумнеешь всё-таки (лет, где-нибудь, через 10), и когда-нибудь поймешь, какую глупость ты тут написал.
Темой одной из заявок на конференцию является конфликт вокруг оператора @. Кто-нибудь в курсе, кто какую точку зрения отстаивает?
SamDark — за собак.
Я, правда, не уверен в общей реализуемости затеи.
Я не за собак, я за гармонию и баланс :)
Если вы в целом против собак, но считаете целесообразным использование их в исключительных случаях, например в процессе записи лога в файл, как это сделано в Yii, то с такой точкой зрения очень сложно спорить. В таком случае странно, что тема вообще оказалась в заявках на devconf.
Вообще, в заявках может оказаться любая тема, чисто by design — форма подачи открыта для всех.
А вот дальше уже идет голосование и отбор. Сказать по правде, я только вчера эту заявку обнаружил, и тоже несколько удивился.
Ну, я имел в виду — чью сторону представлять.
Вообще, сдается мне, представление Григория насчет этого диспута может отличаться от представлений других заявленных участников :)
Григорий спросил, смогу ли я выразить публично свою точку зрения на собачек и хорошо её аргументировать, я согласился.
Ну, проблема в том, что с этой позицией действительно трудно спорить.
Меня ты, по сути, еще в том топике на пхпклубе убедил.
Разве что именно что в две итерации сделать — почему собачки очень-очень плохо, а потом почему иногда все-таки можно.
Но у меня нету четкой картинки как это делать.
И плюс непонятно, насколько это вообще востребовано. Судя по настроению масс — не слишком.
Кто хочет пойти проставьте тут — интересно сколько из 1000 участников читает хабр
habrahabr.ru/company/devconf/events/4921/
А розыгрыши билетов будут как в прошом году от Badoo со слонами? А то для провинции накладно 5к + билеты до Москвы.
Конечно будут — подпишитесь на
twitter.com/devconf_ru
vk.com/devconf
www.facebook.com/groups/devconf/
для полного информирования…

+ конкурс значков и футболок сделаем :-)
Интересует программа второго дня, ибо fisher в 2013м втором год подряд одно и тоже рассказывал. Ожидаю от баду прям такого ухх, как в 2012.
SonkoDmitry,
По второму дню — подтвержденные мастер-классы можно увидеть здесь
devconf.ru/mk

P.S. Fisher — не подавал заявку в этом году. Учитывая тренд в развитии секции Storage — будет что-то по нему.
Будет интересный мк по управлению командой (ведем переговоры) — хороший МК требует хорошей подготовки…
Дак было-же и то и то в прошлом году. Сфинс дак вообще чуть ли не в 2010м еще был.
Не рекламы ради, а просто мнение!

В этом году будет снова Дмитрий Бородин мастер-класс давать. Скорее всего это будет то же самое что и в прошлом году, но если не были, то думаю посетив не пожалеете! Сам лично пересмотрел после его мастер-класса взгляды на то как проектировать приложения. Много для себя почерпнул.

IMHO.
На прошлом DevConf больше всего мне запомнились доклады Александра Календарева, Сергея Мартыненко и мастер-класс Дмитрия Бородина.
А есть тезисы доклада про асинхронный php?
Асинхронный PHP — миф? Реальность!
devconf.ru/offers/14
Был в 2012 – супер! В этом году похоже намечается отличное событие.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.