Хабрахабр:
В блоге Name.com был опубликован рейтинг самых ужасных сайтов мира. Среди этих сайтов есть просто безобразные, есть почти неюзабельные, а некоторые могут служить эталоном банальности и неинтересности. По мнению автора блога, эти сайты настолько отвратительны, что их авторы, должно быть, создавали их под влиянием тяжелых наркотиков. Поэтому, если вы считаете, что дизайн вашего сайта недостаточно профессионален, или же ему не хватает оригинальности и разнообразия, вы можете поднять свою самооценку, взглянув на восемь самых ужасных сайтов в Интернете. Читать дальше →
К своему удивлению, я не нашёл на Хабре исчерпывающей статьи на тему защиты от инъекций. Поэтому решил написать свою. Несколько пространный дисклеймер, не имеющий прямого отношения к вопросуДавайте признаем факт: количество статей (и комментариев) на тему защиты от SQL-инъекций, появившихся на Хабре в последнее время, говорит нам о том, что поляна далеко не так хорошо истоптана, как полагают некоторые. Причём повторение одних и тех же ошибок наводит на мысль, что некоторые заблуждения слишком устойчивы, и требуется не просто перечисление стандартных техник, а подробное объяснение ? как они работают и в каких случаях должны применяться (а в каких ? нет). Статья получилась довольно длинной ? в ней собраны результаты исследований за несколько лет ? но самую важную информацию я постараюсь компактно изложить в самом начале, а более подробные рассуждения и иллюстрации, а так же различные курьёзы и любопытные факты привести в конце. Также я постараюсь окончательно развеять множественные заблуждения и суеверия, связанные с темой защиты от инъекций. Я не буду пытаться изображать полиглота и писать рекомендации для всех БД и языков разом. Достаточное количество опыта у меня есть только в веб-разработке, на связке PHP/MySQL. Поэтому все практические примеры и рекомендации будут даваться для этих технологий. Тем не менее, изложенные ниже теоретические принципы применимы, разумеется, для любых других языков и СУБД. Сразу отвечу на стандартное замечание про ORM, Active record и прочие query builders: во-первых, все эти прекрасные инструменты рождаются не по мановению волшебной палочки из пены морской, а пишутся программистами, используя всё тот же грешный SQL. Во-вторых, будем реалистами: перечисленные технологии ? хорошо, но на практике сырой SQL постоянно встречается нам в работе ? будь то legacy code или развесистый JOIN, который транслировать в ORM ? себе дороже. Так что не будем прятать голову в песок и делать вид, что проблемы нет. Хоть я и постарался подробно осветить все нюансы, но, вполне возможно, некоторые из моих выводов могут показаться неочевидными. Я вполне допускаю, что мой контекст и контексты читателей могут различаться. И вещи, которые кажутся мне сами собой разумеющимися, не являются таковыми для некоторых читателей. В этом случае буду рад вопросам и уточнениям, которые помогут мне исправить статью, сделав её более понятной и информативной. Ещё только начав интересоваться темой защиты от инъекций, я всегда хотел сформулировать набор правил, который был бы одновременно исчерпывающим и компактным. Со временем мне это удалось: Правила, соблюдение которых гарантирует нас от инъекций данные подставляем в запрос только через плейсхолдеры идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде. Всего два пункта. Разумеется, практическая реализация этих правил нуждается в более подробном освещении. Но у этого списка есть большое достоинство ? он точный и исчерпывающий. В отличие от укоренившихся в массовом сознании правил ?прогонять пользовательский ввод через mysql_real_escape_string? или ?всегда использовать подготовленные выражения?, мой набор правил не является катастрофическим заблуждением (как первое) или неполным (как второе). Но вперёд, читатель ? перейдём уже к подробному разбору. Читать дальше →
В этой статье я расскажу о своем опыте разработки кросспостинга из моего Facebook в мой Livejournal (далее ? ЖЖ), а также поделюсь исходными текстами, готовыми к старту на ваших аккаунтах. Причиной написания скриптов было получение возможности поиска по своим записям ? возможности, которую Facebook никак не может запустить как часть своего сервиса, а также ?оживление? своего ЖЖ. Поскольку доступ к любым постам в Фейсбуке требует обязательной авторизации, поисковых роботов сервис, очевидно, не пускает. Конкретно в моем случае это неудобно: ссылки, видео и мысли, которые я публикую в соцсети, зачастую я публикую ?на будущее? ? и часто настает тот момент, когда эта информация становится необходимой, но ее уже практически не найти. Также с использованием опубликованных здесь скриптов удалось перенести архив существующих записей Facebook: более 2000 архивных сообщений моего Facebook перешли в ЖЖ с соответствующими датами. То есть, если у вас еще не было ЖЖ, его можно сразу наполнить информацией за все время. Также в статье выкладываю готовые скрипты на Perl, с использованием которых можно транслировать статусы Facebook в Livejournal, а оттуда, при наличии соответствующих настроек, в Вконтакте, Twitter и RSS, а с использованием дополнительных веб-сервисов ? практически во все блог-движки. Читать дальше →
Товарищи! Эта статья не для high-high-highload систем. Скорость работы представленных решений определённо меньше простейших проверок. На многотысячных или очень глубоких структурах применять предлагаемый подход крайне не рекомендуется. В этом топике побеждает быстрое кодирование, а не быстрый код. Без длинных Давайте без длинных вступлений, но всё же с предысторией. Однажды в рамках создания очередного очень важного компонента веб-сервиса нам понадобилось проверять уйму очень разных входных параметров (в данном случае, пришедших через $_REQUEST). Компонент был очень сложный, внутренняя и внешняя логика вызывала ежедневный баттхёрт между всеми участниками, а отдуваться приходилась немногим ?избранным? программистам, которые писали, переписывали, выпиливали и запиливали заново. Когда на вход в систему с фронтенда падают десятки разных переменных, в том числе массивов, программисты при этом делают перекрёстные задачи (меняя логику) и мешают друг другу ? код очень быстро разрастается, количество цепочек if-ов начинает занимать не одну страницу. Возвращаться к такому коду всё более и более чуждо ранимой душе. Тесты уже не очень помогают, т. к. каждое изменение логики приводит к изменению тех же тестов, в которых ещё надо вспомнить, понять и простить. Вот тогда и встал вопрос о создании удобного способа проверять весь входной поток каким-то приятным глазу способом, да чтоб всегда и везде получать фидбек про ошибки в однотипном виде. Акцент тут изначально стоял именно на удобстве для разработчиков, строго прошу в дальнейшем иметь. Дальше много php
После появления статей типа "Я не знаю ООП" ? возникает желание внести ясность, ?сорвать покровы? и ?докопаться до истины?. Принципы объектно-ориентированности Обычно выделяют (читай: на собеседовании требуют назвать) четыре ?принципа объектно-ориентированного программирования?: абстракцию, инкапсуляцию, наследование и полиморфизм. На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта ? некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного ?функциональности? (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется ?вариантом?, а степень числа ? ?потенцией?), назвали ?методом?. Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской ?записи?, привело к появлению концепции ?наследования?. Читать дальше →
Перевод статьи Джастина Этеридж (Justin Etheredge), в которой автор объясняет тонкую разницу между детерминированными и чистыми функциями. Вчера я читал блог Мэтта Подвизоки (Matt Podwysocki) (этот блог, кстати, потрясающий, идите и подпишитесь), и у него есть пост ?Recursing into Recursion ? Memoization?. Отличный пост, если вы хотите познакомиться с мемоизацией. У меня уже был пост об обобщенной функции мемоизации некоторое время назад, поэтому мы будем говорить не о мемоизации. То, что возбудило во мне интерес, было в конце статьи Мэтта: Не забывайте, что корректная мемоизация требует, чтобы функция, которую вы пишете, была чистой. Это означает, что для одних и тех же входных данных будут вычисляться и возвращаться одни и те же результаты. Моя первая мысль была ?Эй, Мэтт, чистота подразумевает, что функция не имеет побочных эффектов, а детерминированность означает, что функция всегда возвращает одни и те же результаты для данных наборов параметров?. Затем, как у любого хорошего программиста, моей второй мыслью было ?На самом деле, возможно, я не прав?. Поэтому я пошел и изучил этот вопрос, и не удивительно, что я ошибался. Читать дальше →
Отписаться от этой рассылки