Простите, но накипело.
Много шишек уже набито на тему безопасности сайтов. Молодые специалисты, окончившие ВУЗы, хоть и умеют программировать, но в вопросе безопасности сайта наступают на одни и те же грабли.

Этот конспект-памятка о том, как добиться относительно высокой безопасности приложений в вебе, а также предостеречь новичков от банальных ошибок. Список составлялся без учета языка программирования, поэтому подходит для всех. А теперь позвольте, я немного побуду КО.


Итак, каким должен быть безопасный сайт?

Недавно я заметил, что на многих сайтах сделанных на Yii Framework есть одна и та же ошибка:
Если в каком нибудь поле ввода в атрибуте name добавить квадратные скобки и отправить форму, то можно получить сообщение об ошибке, типа:
htmlspecialchars() expects parameter 1 to be string, array given
Иногда даже можно увидеть исходный код PHP файлов, если разработчик забыл убрать константу YII_DEBUG.

Эта ошибка присутствует и на крупных проектах и даже на самом yiiframework.com/search/?q%5b%5d=

Последнее время озабочен темой раннего обучения программированию детей. Увидев неплохую иллюстрацию, решил перевести. Пусть расходится по рунетам, вдруг это подтолкнёт некоторое количество родителей…

Здравствуйте.
В первой части статьи я расскажу о некоторых стилистических «косяках», которые придают текстам характерный канцелярский унылый стиль. Вторая часть посвящена более серьёзной ошибке, которая, к сожалению, грозит в ближайшее время стать правилом.

В настоящее время среди Android-девелоперов большую популярность имеет среда разработки Android Studio, основанная на IntelliJ IDEA от JetBrains. Однако, при использовании данной IDE, могут возникнуть проблемы при разработке приложений, использующих нативный код, так как Android NDK рассчитан преимущественно на использование IDE Eclipse и ADT.

Цель данной статьи — подробное описание процесса создания Android-приложения, использующего NDK в Android Studio, в частности — предложение достаточно простой и эффективной конфигурации gradle (системы сборки пакетов, используемая в Android Studio), гарантирующей включение нативных библиотек в APK-файл. Также статья включает краткую инструкцию работы с NDK в IDE Eclipse и введение в нативную разработку, достаточное для написания первого приложения.

Около полугода назад я стал замечать, что доля javascript’a в моих личных проектах заметно выросла. Выполнять роль заурядного пхпэшника на моём нынешнем рабочем месте стало не в радость. В то же время, создание одностраничных приложений и изучение премудростей фронтэнда доставляло куда больше удовольствия.

А ведь работа должна приносить удовольствие, правда? В итоге появилось стойкое желание сменить поле деятельности и переквалифицироваться из стандартного “PHP Developer” в модного “Javascript/Frontend Ninja”.

Нашел подходящую контору, отправил CV, договорился о дате тестового задания. На тот момент я чувствовал себя достаточно подготовленным, всё-таки за плечами неплохое знание Backbone, парочка одностраничных приложений, эксперименты с Canvas, Google Maps, Node.js, Websockets и прочими. В общем было что показать.

Но тестовое задание приближалось и надо было готовиться. Первым делом я загуглил “javascript interview questions” и тут же прифигел. В голове завертелась мысль: “Почему все эти задания настолько оторваны от реального мира?”

Для разработки приложений фреймворка Meteor существует некоторое число приемов и средств, предназначенных для обеспечения безопасности. В первой части мы поговорим о более известных вещах — скрытии серверной части кода, пакетах autopublish / insecure, скрытии полей коллекций при публикации и встроенной системе учетных записей, заглянув внутрь коллекции Meteor.users. Во второй — про loginToken, выдаваемый клиенту, правила allow/deny при модификации базы данных клиентом, доверенном и недоверенном коде, серверных методах, HTTPS, пакете force-ssl и пакете browser-policy (Content Security Policy и X-Frame-Options), встроенном механизме валидации данных (функция check() и пакет audit-arguments-check).

Если вас не испугала первая часть, предлагаю продолжить разговор о механизмах безопасности Meteor. Начав с loginToken, выдаваемого клиенту, правил allow/deny при модификации базы данных клиентом, коснемся доверенного и недоверенного кода, серверных методов, использования HTTPS и пакета force-ssl, пакета browser-policy (Content Security Policy и X-Frame-Options), и закончим встроенным механизмом валидации данных (функция check() и пакет audit-arguments-check).

Почти год назад я писал о том, как из имеющихся подручных материалов сделать устройство-кронштейн для качественной съемки видео с экрана мобильного устройства и даже получил симметричный ответ – критический очерк о том, что реальная съемка не нужна, а видео работы приложения лучше захватывать с экрана или симулятора.

Сегодня на паре реальных примеров мы рассмотрим разные способы захвата видео с экрана устройств на iOS и увидим, почему автор ответной публикации не прав по многим пунктам – узнаем о достоинствах и недостатках присущих каждому из способов и сделаем для себя соответствующие выводы.

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

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

Спустя время я выделил несколько неочевидных вещей, на которые старался обращать внимание, и в большинстве случаев находил ошибки. Получился небольшой чеклист. Очень полезный как для самопроверки, так и для проверки чужого дизайна. Им с вами и спешу поделиться:

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

В данной статье я хочу рассказать, о том, как можно сверстать «хорошо» (по крайней мере структурировано ;), а заодно рассказать и о методологии, которая может «упростить жизнь» при верстке. Структура поста будет следующей:

• BEM
• Собственно пример — как сверстать страницу

^{Вот так люди видят вашу страницу}

Привет!
Проблема вот в чём. Если зайти на практически любой сайт интернет-магазина или компании с услугами, вы встретите контент. Точнее — отвратительные тексты, которые писали, кажется, маркетологи, воспитанные сеошниками.

Разумеется, можно не делать, как они. Если работать по-умному, то вы поможете и читателям по жизни, и себе в продажах.

По моим примерным подсчётам (усреднение с ряда позиций), конверсии для нас выглядят так:

• Только название и картинка — около 1,5%.
• С описанием от производителя — чуть более 2%.
• С описанием человека, который держал это в руках и знает правила — около 6%.

Ниже — рассказ про то, как мы доводили время на сайте от 3 минут сначала до 6:40, а потом до 20:48. Да-да, двадцати минут сорока восьми секунд для среднего посетителя. Честного среднего, с учётом отказов и по полной выборке.

Во время прикручивания облачных хранилищ к скрипту для бэкапа, встала необходимость использовать OAuth 2 авторизацию, для использования с разными облачными API. В принципе с самой авторизацией никаких сложностей не возникло, но проблема возникла в немного неожиданном месте.

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

Но, не тут-то было…

Предлагаю перейти на сторону зла, на темную сторону программирования. Ситхи сильнее джедаев. И печенек хватит на всех. Предупреждаю, прежде чем начнете читать далее. Характер при переходе на темную сторону портится.
Прошу под кат

Тех, кто так долго ждал этого, я могу поздравить. Тем, кто совсем не ждал, мне сказать нечего, ведь это всё равно свершилось. Сегодня (15 ноября) Google представила первую стабильную версию языка программирования Dart.

Введение

Добрый день.
Однажды я приобрёл Raspberry Pi без каких-то на то целей — как только начались упоминания о нём на хабре. Начал бесцельно запускать фтп-сервера, пробовать Node.js и прочие мелкие серверные дела, пока не приобрёл новый автомобиль. Конечно, заниматься тем, что можно найти на просторах интернета вроде дистанционного открытия гаража я не стал — в силу нормального не знания системы Linux и серверных языков программирования. Автомобиль стал мне дорог и возникла идея — поставить малинку в автомобиль с прикрученными к ней USB девайсами: GPS, Web-камера, 3G-модем — для чего и был куплен 2-ой Raspberry.
В этой статье я опишу подготовку: установку Node.JS, настройку OpenVPN и 3G.

На первый поверхностный взгляд, слова JavaScript и «утечка памяти» рядом стоять не могут. Настоящих утечек памяти в JS, конечно, не может быть, потому что процесс сборки мусора происходит автоматически и не может контролироваться из нашего кода. Выделить память под объект и забыть освободить невозможно. Но могут быть ситуации, связанные с ошибками в логике работы приложения, которые приводят к утечкам памяти другого рода. Например, забиндили обработчик, в котором что-то делаем с методами общего объекта и забыли его анбиндить. Или же посылаем письмо с большим телом и не очищаем тело даже после отправки.



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

Сегодня на глаза попался старый вопрос "Почему работодатель предпочитает нанимать веб-разработчика в офис?": habrahabr.ru/qa/22292. Вопрос был задан еще в 2012 году, но, на мой взгляд, ситуация с тех пор не сильно изменилась.

Коллеги, тут есть серьезное недопонимание, которое давно пора устранить.

Многие, как мне кажется, представляют себе фрилансера примерно так:

• Приходит на какую-то отдельную небольшую задачу, выполняет ее и уходит.
• Работает над несколькими мелкими проектами одновременно. Либо имеет постоянную работу, а фрилансером просто подрабатывает в оставшееся время.
• Его не беспокоит проект в целом. Только то, за что он отвечает.
• Огораживает себя техническими заданиями. И из-за каждой новой плюшки может возникнуть конфликт.
• Работает когда хочет. С ним сложно связаться.

Привет %username%! В начале этого года мне наконец-то исполнился четвертак. Поняв, что я стал взрослым ребёнком и нуждаюсь во взрослых игрушках, купил себе WD My Book Live на 3Tb ёмкости, который в нашем счастливом семействе убил сразу N зайцев. Счастью моему не было предела. Девайс подкупил своей ценой, железом и наличием полноценного Linux на борту. Однако, как оказалось позже, Linux Debian оказался не очень уж и полноценным, достаточно кастрированным и, судя по отзывам рядовых владельцев, любителем окирпичиться. Однако, благодаря инженерам из WD, девайс достаточно легко поднимается из состояния кирпича до состояния работоспособного устройства (пруф1 и пруф2). Но согласитесь, времена хард ресета с пассатижами из хозмага за углом давно миновали. Всё-таки эпоха нано-полимеров и инноваций. А значит и девайс хочется более не убиваемым.

Я никак не являюсь линуксоидом и для меня Linux, по своей сути, тёмный лес! Поэтому, для начала, долго изучая интернеты, я запилил себе только mc и transmission, чего для первого раза мне хватило за глаза. А ещё я был поражён, как мне – человеку, впервые запустившему SSH — легко это удалось! Прошло полгода, я почитал форумы, посвящённые девайсу. Настал день “Д” и я, засучив рукава, принялся делать из своего девайса “конфетку”. И не простую, а “конфетку” с “печеньками”

От переводчика: Это пятая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Как написать приложение Node.js, которое будет продолжать работать даже под невозможной нагрузкой? В этой статье показана методика и библиотека node-toobusy, её воплощающая, суть которой наиболее кратко может быть передана этим фрагментом кода:

var toobusy = require('toobusy');
 
app.use(function(req, res, next) {
  if (toobusy()) res.send(503, "I'm busy right now, sorry.");
  else next();
});

В чём заключается проблема?

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

Это может быть и злонамеренный всплеск трафика, например от DoS-атаки. Первый шаг к борьбе с такими атаками — написание сервера, который не падает.