Намедни встала задача — обеспечить прозрачную авторизацию пользователей домена в CRM, собственно Microsoft давным давно разработал для этих целей метод аутентификации HTTP Negotiate, это все замечательно работает на IIS и Windows Server, а у нас за плечами Samba4 в роли Primary Domain Controller и проксирующий веб сервер nginx. Как быть?

    В сети куча информации по организации подобной схемы для Apache2 & AD на базе Windows, а вот пользователям nginx приходится собирать все по крупицам, информации кот наплакал. В базовой поставке Nginx нет подобного функционала. Благо люди не пали духом и история началась в мейл рассылках nginx в 2009 году, где один американский товарищ из Огайо нанял разработчика на RentACoder для запиливания модуля с подобным функционалом. Ребята форкнули подобный модуль для апача, прикрутили его к nginx и результаты работы выложили на github, где модуль время от времени допиливался разными людьми и в итоге принял роботоспособный вид. Последнюю версию можно получить на гитхабе.

---

В данном руководстве я расскажу как заставить работать nginx с SPNEGO модулем и samba4.

---

Читать дальше →

Котаны!

Вы знаете про Meteor? Ну да — странный вопрос.

Вы знаете про CSS-Modules? Прощай БЭМ.

Вы знаете про SugarSS? Прощай SASS.

Перец из Техаса сегодня принял мой pull-request. И всем этим счастьем теперь можно пользоваться. CoffeeScript, Jade, SugarSS — полный комплект для кошерного кода.

Читать дальше →

Вы можете сказать, что “иногда бывает нужно...” Но на самом деле, вы хотите всегда видеть, что у вас в логах, через графический интерфейс. Это позволяет:

• Облегчить жизнь разработчикам и сисадминам, время которых просто жалко и дорого тратить на написание grep-конвейеров и парсеров под каждый отдельный случай.
  
• Предоставить доступ к информации, содержащейся в логах, умеренно-продвинутым пользователям — менеджерам и техподдержке.
  
• И видеть динамику и тенденции появления залогированых событий (например, ошибок).

Так что сегодня вновь поговорим о стэке ELK (Elasticsearch+Logstash+Kibana).
Но на этот раз — в условиях json-логов!

Такой use case обещает наполнить вашу жизнь совершенно новыми красками и заставит испытать полную гамму чувств.


Читать дальше →

Стараясь оставаться в тренде и следуя веяниям моды веб разработки, последнее веб приложение я решил реализовать как набор микросервисов на ruby плюс “толстый” клиент на ember. Одна из первых проблем, вставших перед мной была связана с аутенфикацией запросов. Если в классическом, монолитном, приложении все просто, используем куки, сессии, подключаем какой-нибудь devise, то тут все как в первый раз.

Архитектура

За базу я выбрал JWT — Json Web Token. Это открытый стандарт RFC 7519 для представления заявок (claims) между двумя участниками. Он представляет из себя структуру вида: Header.Payload.Signature, где заголовок и payload это запакованые в base64 json хэши. Здесь стоит обратить внимание на payload. Он может содержать в себе все что угодно, в принципе это может быть и просто client_id и какая-то другая информация о пользователе, но это не очень хорошая идея, лучше передавать там только ключ идентификатор, а сами данные хранить где-то в другом месте. В качестве хранилища данных можно использовать что угодно, но мне показалось, что redis будет оптимальным, тем более что он пригодится и для других задач. Еще один важный момент — каким ключем мы будем подписывать наш токен. Самый простой вариант использовать один shared key, но это явно не самый безопасный вариант. Коль скоро мы храним данные сессии в redis, ничто не мешает нам генерировать уникальный ключ для каждого токена и хранить его там же.

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

Facebook _ ის კომენტარების ფორმა ყველა Dle საიტისთვის