Один французский «исследователь безопасности» этим летом опубликовал невиданно много найденных им уязвимостей типа arbitrary file upload в разных «написанных на коленке», но популярных CMS и плагинах к ним. Удивительно, как беспечны бывают создатели и администраторы небольших форумов, блогов и интернет-магазинчиков. Как правило, в каталоге, куда загружаются аватары, резюме, смайлики и прочие ресурсы, которые пользователь может загружать на сайт — разрешено выполнение кода PHP; а значит, загрузка PHP-скрипта под видом картинки позволит злоумышленнику выполнять на сервере произвольный код.

Выполнение кода с правами apache — это, конечно, не полный контроль над сервером, но не стоит недооценивать открывающиеся злоумышленнику возможности: он получает полный доступ ко всем скриптам и конфигурационным файлам сайта и через них — к используемым БД; он может рассылать от вашего имени спам, захостить у вас какой-нибудь незаконный контент, тем подставив вас под абузы; может, найдя параметры привязки к платёжной системе, отрефандить все заказы и оставить вас без дохода за весь последний месяц. Обидно, правда?

К своему удивлению, я не нашёл на Хабре исчерпывающей статьи на тему защиты от инъекций. Поэтому решил написать свою.


Ещё только начав интересоваться темой защиты от инъекций, я всегда хотел сформулировать набор правил, который был бы одновременно исчерпывающим и компактным. Со временем мне это удалось:

Правила, соблюдение которых гарантирует нас от инъекций

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

Всего два пункта.
Разумеется, практическая реализация этих правил нуждается в более подробном освещении.
Но у этого списка есть большое достоинство — он точный и исчерпывающий. В отличие от укоренившихся в массовом сознании правил «прогонять пользовательский ввод через mysql_real_escape_string» или «всегда использовать подготовленные выражения», мой набор правил не является катастрофическим заблуждением (как первое) или неполным (как второе).

Но вперёд, читатель — перейдём уже к подробному разбору.

После пяти с половиной месяцев разработки с момента выхода предыдущей версии, очень рад наконец представить вам Leaflet 0.4 — новую версию легковесной JavaScript-библиотеки для интерактивных карт, которая одинаково хорошо работает и на десктопных браузерах, и на мобильных устройствах.

Этот релиз, к которому приложило руку 33 разработчика, несёт в себе более простой, удобный API и громадное множество улучшений и исправлений вместе с масштабным обновлением документации, запуском официального блога и страничкой плагинов. Давайте рассмотрим улучшения по порядку.

Привет всем!

Хочу представить вам Карту Интернета или результат кластеризации более чем 350 тысяч сайтов в соответствии с переходами пользователей между ними. Размер круга определяется посещаемостью сайта, цвет – национальной принадлежностью, а положение на карте – его связями с другими сайтами. Если два сайта имеют стабильный поток пользователей между ними, то они будут «стараться» расположиться ближе друг к другу. После завершения работы алгоритма, на карте можно наблюдать скопления сайтов (кластеры) объединенные общими пользователями.



Например, если ввести в поиск habrahabr.ru, то можно увидеть, что dirty.ru и leprosorium.ru в том же «созвездии», а еще подальше livejournal.ru. Это говорит о том, что тот, кто сейчас читает этот текст, также с высокой вероятностью посещает эти сайты (относительно усредненного пользователя Рунета конечно).

Еще более интересный пример кластеризации можно увидеть внизу карты, между фиолетовой Японией и желтоватой Бразилией: там расположилась целая порнострана по размерам сопоставимая со всем Евронетом. Интересно, что будучи достаточно компетентным в рассматриваемом вопросе, внутри большого порнокластера можно различить тематические подкластеры меньшего размера.

Тем, кого интересует краткое техническое описание – добро пожаловать под кат

Весной я писал как построить дешевый и простой коптер за 1 день и $120
Основной его недостаток — довольно примитивный по возможностям контроллер KKmultiсopter — он даже горизонт сам держать не умеет. Что-ж, исправим этот недостаток!
Тех, кто уже построил по предыдущему рецепту, спешу успокоить — бюджет апгрейда всего $40-55. Для тех, кто строить будет с нуля, есть возможность улучшить конструкцию.
Я построил второй коптер, т.к. комплектующие для него были куплены давно.

В комментариях к предыдущему посту про иероглифы сказали, что хорошо бы иметь такую же блок-схему для кракозябр.

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

Сегодня сложно найти интернет-проект, который бы не общался со своей аудиторией посредством электронной почты. С другой стороны, ежемесячная аудитория Почты Mail.Ru составляет почти 23 миллиона человек. Это значит, что среди получателей ваших посланий наверняка будет много (даже очень много) адресов в доменах mail.ru, bk.ru, list.ru и inbox.ru. Скажем прямо, у многих популярных проектов более половины пользователей – с адресами на mail.ru.


Как вы можете узнать, что ваши рассылки успешно доходят до этих пользователей? Как вы можете увеличить их эффективность? Как вы можете отслеживать статистику жалоб на ваши письма как спам? Раньше честный ответ был: «никак». Но сегодня Почта Mail.Ru готова с гордостью анонсировать появление панели управления рассылками, предназначенной специально для веб-мастеров – postmaster.mail.ru. Внимание, вы видите это первыми! Мы еще не публиковали официальных пресс-релизов про этот инструмент, поскольку хотим поделиться с аудиторией Хабра и получить ваш фидбек.

Итак, что такое Postmaster?

Данная статья является вольным переводом. Оригинал тут.

Введение

Думаю, ни для кого не секрет, что клиентские приложения в современных веб-сервисах становится все сложнее и количество JS кода в них растет. До недавнего времени архитектура клиентской части, как правило, разрабатывалась с нуля и была специфична для каждого проекта. Не удивительно что приходилось снова и снова сталкиваться с типичными задачами.
К MVC-фреймворкам на серверной стороне все уже привыкли, но JS код на клиенте часто бывает плохо структурирован.

Предлагаю ознакомиться с решением на базе backbone.js, underscore.js и jQuery, которое поможет решить эту проблему.

Постановка задачи

Каким бы мы хотели видеть наше приложение? Вот основные моменты, которые мне кажутся важными:

1. Должен быть удобный способ описать модели нашей предметной области.
2. Любые изменения в модели должны немедленно отражаться в пользовательском интерфейсе, если модель в нем представлена каким-либо образом.
3. Понятная и легко-поддерживаемая структуризация кода в стиле MVC.

Попробуем решить эти задачи на примере простого приложения «Каталог фильмов».

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Есть сейчас такая тенденция — делать в сайтах поддержку планшетов iPad и других устройств на iOS: iPhone, iPod. Но если для сайтов это достаточно просто, при хорошей верстке, можно добавить пару тегов в head и готово, то для веб-приложений, где есть сессии с использованием Cookies, все обстоит сложнее и есть подводные камни. Итак, возможно, еще не все знают, что в мобильном Safari можно нажать кнопку меню (со стрелкой, как на рисунке) и выбрать там «Добавить в Домой» / «Add to Home Screen», тогда для сайта появится иконка на рабочем столе. Но иконка будет просто запускать Safari с этим сайтом, а вот если добавить пару известных тегов (см. ниже), то все элементы управления Safar будут скрыты и приложение будет работать на полный экран, как обычные нативные приложения iOS. Так вот основная выявленная проблема в том, что в этом режиме сессия все время сбрасывается. Стоит переключится на другое приложение или рабочий стол, даже просто перейти по ссылке, и опять вернуться в веб-приложение, как страница перегрузится и сессионной Cookie уже не будет, нужно логиниться заново. Эту проблему то мы и решим.

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

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

Данный пост является переводом не статьи, как принято, а доклада+презентации, поэтому текст поста достаточно вольный.

Думаю, всем хорошо известно и очевидно, что PHP — один из самых популярных языков программирования, на котором написано множество веб-проектов, начиная с персональных homepage-страниц и заканчивая мастодонтами типа Facebook, Vimeo, WordPress и даже YouPorn.

PHP появился в 1995 году, при этом полноценная поддержка ООП была реализована только в PHP5, который вышел в 2005 году. За это время было написано большое количество кода, как хорошего, так и плохого, а точнее сказать сильно устаревшего и тяжело сопровождаемого.

Многие проекты, как и экосистема PHP в целом, к настоящему моменту стали представлять подобие оживленного городского квартала.

Фреймворк для автоматического тестирования веб-приложений на PHP — Codeception живет и развивается. Но в этот раз вместо скупой порции новостей я бы хотел представить вам первый скринкаст в котором показаны азы работы с Codeception. Если вы только читали про Codeception, то вам обязательно стоит взглянуть на него в действии. Ну а если не читали, но у вас есть веб-сайт, который бы вы хотели протестировать — тоже взгляните.

Я и пару моих друзей недавно самостоятельно решили заняться разработкой приложений под IOS. Ну и понятно что сразу начали «набивать шишки», но когда я случайно наткнулся на серию статей — понял что найди я их раннее, возможно многие вопросы в нашей работе и не возникли бы.
Итак я решил поделиться переводом первой статьи из четырех (перевод сделал самостоятельно, жестко к тексту не привязывался, ссылка на источник в конце статьи).

Фаза «предразработки» приложения

Прежде чем приступить к реализации вашей идеи вы должны задать себе пять вопросов:
1. Кто будет использовать ваше приложение?
2. Какие у вас конкуренты?
3. Почему ваше приложение уникально?
4. Когда вы его выпустите?
5. Как люди будут взаимодействовать с вашим приложением?

Рассмотрим каждый вопрос по отдельности.

У многих из нас, бывают ситуации когда проект требует подготовки к выводу в продакшн, и зачастую эта подготовка состоит из множества действий, которые приходится выполнять много раз(например при сборке релизной версии). Зачастую задачи сводятся к выполнению простых консольных команд, очистке кеша, минификации JS и CSS или сборки их в один файл, но вся эта рутина может занять довольно продолжительное время, а так как выполняется, чаще всего, в конце рабочего дня, довольно легко опечататься и отправить несколько дней\часов\минут работы над проектом в небытие. В такой ситуации программисты стараются, как то автоматизировать сборку и подготовку проекта к рабочему состоянию, в чём им помогают различные системы сборки, об одной из которых и пойдёт речь в статье.

Привет, у нас довольно большой поток разношерстных проектов. В какой-то момент нам пришла в голову светлая идея создать внутреннюю хартию ведения проектов, с которой соглашается каждый участник команды. Есть надежда, что это сократит издержки, увеличит качество и уменьшит количество неразберихи, позволит проще вводить новых «игроков» и вообще В качестве системы управления проектами выбрана Redmine, и надо сказать даже в default устанвоке эта штука правильно решает много вопросов за тебя: разделение на Ошибка\Улучшение, интеграция Git, лог действий, подпроекты, удобная Wiki и.т.д.

Всё началось с того, что мы задумали веб портал для продажи мебели. Это веб портал для продажи предметов мебели и интерьера, и что у меня самого есть множество идей, которые мы должны реализовать в рамках будущего портала. Все эти идеи были похожи на интернет-магазин, но при этом они не совсем укладывались в рамки обычного магазина. Например, товары мы должны показывать в красивых интерьерах реальных квартир — это интересно, а главное удобно для покупателя. Значит, у нас на сайте должны быть отдельно карточки и интерьеров и товаров, которые образовывают структуры. Вот еще задачка: сам портал не имеет своего склада и логистики, а только агрегирует информацию: собирает, анализирует, красиво показывает и генерирует продажи у партнеров. Значит нужно ввести различных поставщиков, показывать различные условия доставки и т.д. Поэтому перед нами встал вопрос: что мы можем использовать, чтобы создавать портал не с нуля, но при этом иметь большую гибкость при кастомизации выбранных решений. Итак, что же у нас получилось.

Выбор LAMP
Вначале мы выбрали общий стек технологий. Здесь было просто: ведь наиболее распространённый выбор технологий для веб-порталов — это LAMP (Linux, Apache, MySQL, PHP). Мы не хотели изобретать велосипед, писать все с нуля, так как это и дорого и долго. Нам нужно было максимально быстро создать портал с использованием каких-либо библиотек/фреймворков, возможно CMS/E-commerce систем. Если LAMP технологии наиболее распространены — то значит, мы сможем найти большое количество различных open-source решений, а из них сможем выбрать что-то подходящее для «фундамента» своего портала.

Готовые E-commerce системы
Как только мы выбрали PHP и все, что с ним связано, мы начали смотреть, что уже есть готового по нашей тематике. Конечно же, мы сразу начали думать про готовые E-commerce системы, например, набирающую популярность Magento. Нашли нескольких партнеров Magento, которые занимаются кастомизацией и внедрением этой системы. Попросили сделать примерную оценку того, во сколько нам обойдется «заточить» Magento под все наши требования, включая оптимизацию быстродействия, с которым у Magento, как оказалось, есть сложности, особенно у бесплатной версии. Наши расчеты показали, что по стоимости работ и дальнейшей поддержке в краткосрочном периоде — это будет даже дороже, чем, если бы мы писали все с нуля на чистом PHP. Мы посмотрели другие E-commerce решения: osCommerce, ZenCart, PrestoShop. Здесь ситуация была примерно такая же, а может даже хуже. Таким образом, мы вернулись в исходную точку поиска.

Фреймовики и библиотеки
Тогда мы решили смотреть в сторону более общих решений: фреймворков и библиотек. Мы решили остановиться на выборе 3-ех наиболее популярных фреймворков: Zend 1.11, Symfony 2 и Yii. Здесь у нас был более технологичный подход к выбору: мы хотели полную поддержку PHP 5.3, причем, желательно, чтобы сам код фреймворка предполагал стиль написания PHP 5.3, а именно как можно больше ООП, ведь нам же это все еще поддерживать потом. От Zend отказались сразу. Он очень монструозный, а нам нужно процентов 20 от его функциональности. К тому же ожидаемый 2.0 тогда был еще в форме идей на сайтах основных разработчиков. Yii был еще очень свежий на тот момент (осень 2011 года), а мы знаем, чем бывают чреваты эти «горячие пирожки» (как показало время – версия Yii 2.0 с полной поддержкой PHP 5.3 пишется до сих пор). И мы решили не рисковать и взять наиболее готовый и стабильный продукт – Symfony 2.

ORM решения
Итак, у нас были выбраны и платформа и фреймворк: LAMP + Symfony2. Нам также нужно было решить проблему с уровнем хранения и представления данных в нашем портале. Наверное, хорошо написать что-то специфическое для себя – это и работает быстрее и меньше кода. Однако основная наша проблема была в том, что мы делали свой продукт, и у нас не было четкой и постоянной спецификации. Улучшения же (читай: частые изменения) в сущностях, их взаимосвязях и бизнес-логике, требовали какого-то гибкого решения, которое мы могли бы быстро изменять и не бояться получить массу regression багов. В данном случае мы пошли хорошо проторенной дорогой. Сейчас большую популярность набирают различные ORM решения. Это не зависит от стека технологий или домена приложения. Посему после недолгих рассуждений мы выбрали ORM Doctrine 2. Тем более что она входит как стандартный модуль в Symfony 2. К тому же, мы понимали, что с ростом объемов данных и взаимосвязей между сущностями при работе на портале, мы перейдем к использованию нереляционной СУБД, например, MongoDB, а с выбранной ORM – Doctrine это также просто реализуется.

Итого у нас получился интересный набор технологий:

LAMP + Symfony 2 + Doctrine 2.

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

Работать дизайнером очень интересно. Это творческая работа. И как любому творческому человеку, дизайнеру нужна муза или вдохновение.

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

Естественно, если вы расскажите о своих ресурсах, я буду благодарен.

Хочу сразу предупредить, что практически все ресурсы, собранные мной — англоязычные. Только лишь один на русском. Так же я не очень приветствую узкопрофильные ресурсы (речь о ресурсах, на которых можно скачать только кисти для photoshop и прочее).

Composer (getcomposer.org) — это относительно новый и уже достаточно популярный менеджер зависимостей для PHP. Вы можете описать от каких библиотек зависит ваш проект и Composer установит нужные библиотеки за вас! Причём Composer — это не менеджер пакетов в классическом понимании. Да, он оперирует с сущностями, которые мы будем называть «пакетами» или библиотеками, но устанавливаются они внутрь каждого проекта отдельно, а не глобально (это одно из основных отличий от старого-доброго PEAR).

Кратко, как это работает:

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

При создании Composer авторы черпали идеи и вдохновение из аналогичных проектов: npm для Node.js и Bundler для Ruby.

Изначально он был спроектирован и разработан двумя людьми Nils Adermann и Jordi Boggiano, сейчас в проекте участвует более двадцати контрибьюторов, Проект написан на PHP 5.3, распространяется под лицензией MIT и доступен на github.

Первые коммиты были сделаны апреле 2011 года и на сегодняшний день Composer находится в стадии «alpha3». Однако, он уже достаточно стабилен и используется многими популярными PHP проектами (например, Symfony 2). Список проектов использующих Composer можно посмотреть на сайте packagist.org — это официальный репозиторий Composer пакетов. Кстати, на недавней конференции Devconf 2012 разработчик фреймворка Yii в своём докладе упомянул, что Yii2 скорее всего тоже будет использовать Composer.

В этой статье я кратко опишу основные возможности Composer и мы попробуем создать демонстрационный проект использующий Composer для загрузки необходимых библиотек. Все примеры будут доступны на github.com и bitbucket.org.

Kickstrap это то, что будет если соединить Twitter Bootstrap, HTML5 Boilerplate, значки от IcoMoon и Font Awesome, добавить проверенные jQuery плагины Chosen и jGrowl, включить поддержку разных цветовых схем и тем оформления Bootswatch, дополнительную CSS сетку и вменяемую поддержку ранних версий IE.