Аутентификация в rails-приложениях через facebook, vkontakte

В данной статье будет рассказано, как сделать простейшую аутентификацию в rails-приложении через социальные сети vkontakte и facebook, помогают в этом гемы omniauth, omniauth-facebook, omniauth-vkontakte. Материал рассчитан на новичка. Хоть это и будет учебное приложение, но для придания законченности используем bootstrap с помощью гема twitter-bootstrap-rails.

С данной темой доклада я выступал на CodeFest. А здесь я перескажу словами, что, как и зачем.


Доклад довольно поверхностный и не требует практически никакой квалификации в области ИБ. Был рассчитан на целевую аудиторию (веб-разработчики, тестировщики (не на проникновение), сисадмины и т.д.). Все довольно просто: несколько утилит, запустили, подождали, разбираем отчет.

Видеоприглашение на конференцию:

Все дела сделаны и теперь есть время черкануть пару строк об автоматизации тестирования…

С развитием браузерных MVC-фреймворков, Rails очень часто стали упоминать в контексте удобного фреймворка для REST-провайдеров. Мы тоже используем Rails для этой цели и достаточно долго. Есть, однако, очень большая проблема: представления. Вьюшки, которые описывают структуру JSON для ответа.

На первый взгляд, все просто отлично. Ничего кроме .to_json или RABL, в некоторых сложных случаях, не требуется. Но затем ситуация выходи из под контроля. И идут бесконечные циклы перебора JSON-билдеров в поисках лучшей жизни.

Проблема

Давайте возьмем для примера банковский сервис. Он состоит из 30 моделей. Каждая модель представлена CRUD-реурсом (в каждом по 3-4 расширяющих метода). В каждой модели 10-12 полей и это обычно длинные строки. И, конечно, все они связаны. Вплоть до 4-5 уровней belongs_to.

При этом важно помнить, что в реальной жизни JSON ответа – это не просто прямой дамп структуры модели. В нем постоянно встречаются условия (какой атрибут должен попасть в ответ? Зависит от другого атрибута) и кастомные методы.

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

Всем доброго времени суток!

Введение

На написание этого поста меня сподвигло слишком малое количество материала о sinatra, и тем более о данной связке. Надеюсь для кого то этот пост будет полезен. Ниже я опишу как можно совместно использовать sinatra, mongodb и carrierwave, на примере создания простой фотогалереи. Для общения между sinatra и mongodb мы будем использовать отличный gem — mongoid. По умолчанию предполагается что у вас уже установлен ruby и mongodb. Приступим.

В позавчерашнем выпуске «Mozilla Hacks Weekly» увидал гиперссылку «Morris.js», пошёл по ней, почитал, порадовался — а теперь и вам поведаю.

Morris — это легковесный джаваскрипт (всего-то 3052 байта после миниатюризации) с открытым исходным кодом (распространяемым по упрощённой лицензии BSD), который для работы требует jQuery и Raphaël и строит с их помощью графики на простой сетке горизонтальных линий, наподобие такого:



По оси абсцисс откладывается время, по оси ординат — какие-нибудь зависящие от времени значения. (Morris изначально разрабатывался для сайта, показывающего общее число автомашин той или иной марки в Великобритании, так что для него естественно, что ось абсцисс — это ось времени.)

Графики реагируют на мышь: вспучиваются точки, соответствующие указанному мышью моменту во времени, и подле них появляются подсказки.

Достоинство скрипта — простота API. Приведённый мною пример создаётся вот таким вызовом:

// поквартальные данные, тонкие линии, цвета их заданы в явном виде
Morris.Line({
  element: 'quarterly',
  data: [
    {q: '2009 Q3', a: 100, b: 75},
    {q: '2010 Q2', a: 75, b: 50},
    {q: '2010 Q3', a: 75, b: 50},
    {q: '2011 Q1', a: 50, b: 25},
    {q: '2011 Q3', a: 50, b: 25},
    {q: '2011 Q4', a: 75, b: 50},
    {q: '2012 Q2', a: 100, b: 75}
  ],
  xkey: 'q',
  ykeys: ['a', 'b'],
  labels: ['Series A', 'Series B'],
  lineColors: ['#167f39','#044c29'],
  lineWidth: 2
});

У многих людей, как-либо связанных с безопасностью, периодически возникает желание заняться pentest'ом, то есть тестом на проникновение. И чаще всего начинают все с pentest'а веб-приложений. Порог вхождения довольно мал (простейшая sqli определяется добавлением кавычки в параметр и эксплуатируется не особо сложнее), но при этом встречаются и довольно сложные задания, которые заставляют потратить пару-тройку дней на ковыряние.
Но возникает вопрос — где применять теоретические знания, без страха внезапного появления маски-шоу? Под катом проведу небольшой обзор полигонов для экспериментов по pentest'у.

Хотя на Хабре уже проскакивали статьи о создании гемов, они либо содержат устаревшую, либо неполную информацию.

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

Современный подход заключается в использовании Bundler совместно с другими инструментами, такими, как Git, YARD и RSpec-2.

The Little Redis Book — это бесплатная книга про Redis.

Книга была написана Karl Seguin, при поддержке Perry Neal. Karl Seguin является также автором книги The Little MongoDB Book, которую часто рекомендуют для быстрого старта с MongoDB. Первая версия повилась около недели назад.

Сегодня я сделал первую версию перевода этой книги. Исходные тексты доступны в репозитории на GitHub. Там же можно найти и готовый PDF.

Перевод выполнен с целью популяризации Redis среди русскоговорящих разработчиков. Книга является очень удобным и компактным руководством.

Я благодарен следующим людям за помощь в переводе оригинального текста и вычитке результата:

• Dmitry Scriptin
• Денис Веселов
• polinom

Я прошу все неточности и опечатки отправлять для коррекции перевода.

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

Как обнаружить, что база данных повреждена

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

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file 'D:\Develop\Databases\Broken1.mdf'.

Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816.

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

На прошлой неделе компания LMAX, где я работаю, получила приз Java Duke's Choice Award 2011 за фреймворк Disruptor. Ранее об этой технологии писал Martin Fowler, известный многим читателям публикациями об объектном программировании.

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

Некоторое время назад я гуглил интернет по поводу “REST vs SOAP”, прочитал пару статей и вроде бы все понял, но не почувствовал от этого никакого удовлетворения. Что-то было не так, то ли я не почувствовал основную идею, то ли просто читал, одновременно слушая новый музон и думая о новой фиче в проекте. Как появилось время, решил восполнить этот пробел, заодно написав полезную статью по этому поводу.

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

Несколько недель назад, мы публично выпустили Gauges API. Несмотря на уже существующий Gauges, было не мало работы во время написания API. Необходимо подробно разобраться с деталями.

1. Пишите документацию во время создания API

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

2. Будьте постоянным

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

Чтобы решить массив/хэш проблему, мы выбрали в качестве ответа всегда возвращать хэш. Это самое гибкое решение, ориентируясь на наши будущие задачи. Мы смогли ввести новые ключи, без нужды конвертировать ответ от нашего сервиса или выпуска новой версии API.

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

{users:[{user:{...}}, {user:{...}}]} // нет
{users:[{...}, {...}]} // да
{username: 'jnunemaker'} // нет
{user: {username:'jnunemaker'}} // да

Ну вы поняли. Постоянство ― важно. Всегда следует придерживаться одного формата.

БЭМ расшифровывается как «Блок Элемент Модификатор». Это подход к web-разработке, позволяющий быстро создавать сайты с гибкой архитектурой. Он знаком многим, кто занимается HTML/CSS вёрсткой.

Изобретённый в Яндексе, БЭМ постепенно проникает и в разработку других компаний.
В данный момент основные мейнтейнеры работают над выводом в Open Source фреймворка, построенного по методологии БЭМ, инструментов и многих полезных утилит.

Вчера, 17 ноября, прошло ежегодное вручение наград лучшим стартапам, The Europas. Выбор по 22 номинациям осуществлялся как на основе голосования экспертов, так и по результатам 40,000 голосов посетителей сайта theeuropas.com.

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



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

Супервизор сервисов runit позиционируется как замена стандартным скриптам инициализации Unix.

Но на практике оказалось, что runit идеален для управления сервисами безотносительно инициализации и т.п.

Введение

Супервизор берёт на себя такой функционал, как:

• превращение любого процесса в демон;
• логгирование вывода процесса и ротирование логов;
• запуск, остановка, рестарт, запрос состояния, управляющие скрипты для init.d;
• выключение и запуск сервисов автоматически при появлении новых сервисов в списке либо удалении старых из списка;
• возможность ведения нескольких независимых списков сервисов одновременно (например, для каждого пользователя отдельно и для системы в целом);
• удобный API для управления сервисами.

Для большинства операционных систем runit уже входит в репозитории пакетов (apt-get install runit). Кроме того, мы имеем уже готовый набор рецептов для популярных сервисов (nginx, apache etc.).

Мы снова приветствуем вас на волнах Changelog FM, и сегодня у нас в студии — Ajenti 0.6.0.

Что за Rack?

По словам Christian Neukirchen — автора гема rack — он создан для обеспечения минимального API для подключения веб-серверов, поддерживающих Ruby (WEBrick, Mongrel и т.д.) и ruby веб-фреймворками (Rails, Sinatra и др.).

Такие фреймворки, как например Sinatra, построены над Rack или у них есть rack-интерфейс, позволяющий серверам веб-приложений подключаться к ним.

Цель rack проста — он позволяет с легкостью обрабатывать HTTP-запросы.

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