Редизайн устаревшего личного кабинета: не повторяйте наших ошибок

Меня зовут Евгений Цветков и я расскажу, что надо учитывать при редизайне интерфейсов, чтобы малыми средствами получить большой результат.

Телфин на рынке телекоммуникаций с 2003 года. За 13 лет у пользователей расширился выбор настроек телефонии. Интерфейс личного кабинета абонента по разным причинам не менялся. И в один прекрасный день он настолько устарел, что стал представлять из себя квест «Угадай нужную кнопку».

Так выглядел личный кабинет компании еще недавно:

Хозяйке на заметку: Когда функционал расширяется, просто добавлять очередной пункт в меню – опасно. Иначе получится комбинация горизонтального и вертикального меню, прямо как на картинке выше. Вспомните об этой картинке, когда попросите программиста «дорисовать ещё одну кнопочку левее».

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

  • «Даже шаблоны по умолчанию в распространённых движках WordPress, Drupal, OpenCart выглядят раз в 100 лучше».
  • «Да просто сделайте всё не для технарей, а для ЛЮДЕЙ».

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

С чего начать?

Шаг 1. Начнем с опроса клиентов

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

Такой обзор от клиента достоин фирменной кружки:

Ответили сотни абонентов. Порадовало, что клиенты писали, в основном, по делу и с душой подошли к вопросу улучшения нашего продукта.

Часть клиентов предложила нам ничего не менять — «уже привыкли»:

Шаг 2. Создаем структуру с учетом мнения пользователей

Что в личном кабинете абонентам нужно в первую очередь?

  • Оплачивать телефонию и следить за расходами.
  • Видеть общую статистику звонков.
  • Менять настройки приема входящих вызовов.

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

Шаг 3. Компонуем страницы

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

Бывает, спрашиваю коллег «Зачем это?» — а про это никто и не знает. Такая история была с книгой контактов быстрого набора для callback. В настройках забиваешь телефонные номера, присваиваешь им 1-2-3, потом набираешь короткие номера вместо длинных. Но кому это было надо? А я проверил. Из многотысячной аудитории Телфин только у 35 пользователей существовали хоть какие-либо настройки данной книги (и то, не факт, что ей пользовались). Предвкушая вопросы, функция не удалена. Она сохранена, просто убрана из интерфейса.

Шаг 4. Делаем прототип

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

Прототип выглядел так: xrc41w.axshare.com

Концептуально прототип утвердили. Переходим к шагу 5.

Шаг 5. Критика

Часть поправок в интерфейс была внесена уже на этом этапе. Раздел «Услуги» обсуждал с руководителем саппорта, «Финансы» — с руководителем клиентского отдела. «Главную» — со всеми, кто работает с клиентами. Чем больше общались, тем лучше становился прототип.

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

Мы постоянно что-то ломали, переделывали. Топы поняли, что если не будут активно предлагать изменения сейчас, они будут жить с тем кабинетом, который получится, а не который хочется. Так что никого не надо было заставлять принимать участие в обсуждении. Мы работали как художники. Вдохновлено и преданно. И хотя в итоге реализовали 95% из того, что хотелось бы, но мы сделали гораздо больше изменений, чем рассчитывали изначально. Итог показали агентству, внесли еще несколько небольших правок и составили ТЗ для дизайна.

Шаг 6. Отправляемся в дизайн-агентство с ТЗ

Здесь приятное ожидание макета от Aidem (наконец, можно было всем заняться своими прямыми обязанностями).

Желтовато, но в целом отлично:

Мы изменили итоговую гамму на более фирменную: оранжево-голубую. Что-то перекомпоновали, что-то изменили порядочно. Проводили совместные встречи с каждым руководителем и командой Aidem, когда сдавали каждый из блоков.

Шаг 7. Написали спецификацию для верстки

Спецификация: yadi.sk/i/SMQSQPaloEhVr

Спецификация для верстки включала самые важные вещи и составила 30 страниц.

Header​……………..3
Footer​……………………………………3
Главная страница​………………3
Первый вход​………6
Последующие входы​……6
Общие элементы​………..7
Документы и платежи​……8
Блок “Информация по договорам и тарифам”​………………..9
Блок “Документы по договорам”​……….11
Блок “Счета и платежи”​…12
Выставление счета​ (модальное окно)…..12
Заказ акта сверки​……..14
Подключенные линии​…………………15
Настройка АОН​……….17
Настройка переадресации​…..18
Настройка голосовой почты​………….19
Пополнение счета​…………..21
Обещанный платеж​……………..22
Подтверждение оплаты​….23
Выставление счета​………..27
Результат денежного перевода………..30
Уведомления​………………….31


Вот так подробно коллеги из Aidem описывали каждый пункт:

Шаг 8. Сегодня мы с тобой верстаем

Хотя макет заказали в агентстве, дальше все снова свалилось на наши плечи. Мы решили делать верстку своими силами, без привлечения сторонних специалистов. В основном, по причинам безопасности.

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

Шаг 9. Внутреннее тестирование

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

Шаг 10. Быстрый запуск и правки по живому

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

Дизайн и навигация

Нечитаемый шрифт, неподходящие цвета

Из опрошенных клиентов 40% жаловались на устаревший дизайн и сложную навигацию: шрифт был мелким и сложно читался, меню казалось непонятным. Многие опрошенные просили большие кнопки. Для оформления нового личного кабинета мы использовали уютную цветовую гамму, сделали текст легким для чтения, переписали основные тексты и комментарии. Убрали фон у записей и полностью изменили главное меню (не только по функционалу, но и по внешнему виду).

Легкий, современный, красивый, минималистичный — таким хотели видеть личный кабинет клиенты, и мы это сделали. Верстали «дивами» с применением HTML5, CSS3, хотя, уверен, все равно пытливые умы найдут косяки.

Хозяйке на заметку:
Мы выпустили к десктопной версии кабинета мобильную только спустя пару месяцев после обновления и с ограниченным функционалом. В будущем, конечно, можно будет полностью управлять настройками со своего смартфона. Однако сегодня все исповедуют мобайл ферст, когда первым делом делают дизайн мобильной версии.

Спрашивали — отвечаем

  • «Более информативная главная страница»
  • Есть
  • «Дизайн в стиле каменного века»
  • Теперь это в прошлом
  • «По сравнению с сайтом личный кабинет выглядит ужасно!»
  • Мы исправились
  • «Сделать современный плоский дизайн с использованием AJAX»
  • Есть

Иерархия

В старом Кабинете было легко заблудиться.

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

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

Главная страница

Несложно заметить разницу между старой главной страницей и новой. Мы изменили практически всё. Убрали лишние пункты меню, оставили только название, код клиента, а под ним баланс и кнопку «Пополнить счет». На главной странице теперь — описание сервисов, которыми клиент пользуется и ссылки на полезные страницы.

Найди 5 отличий:

Подсказки

Интересно, что 10% опрошенных просили сделать подсказки.

«Как-то сделать более «дружественным» интерфейс, — подсказки, как в поисковике, предложения, советы»

Требование справедливое. Телекоммуникации — специфическая и сложная сфера, в которую клиент не обязан глубоко вникать, а SIP ID, линия, очередь, API — все это требует пояснения.

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

Добавили описание дополнительных опций маленьким серым шрифтом:

Пример подсказок желтого цвета:

Для быстрой помощи клиентам мы добавили в личный кабинет онлайн-чат. Теперь можно не звонить, не писать письмо, а решить свой вопрос онлайн.

Онлайн-чат клиентской поддержки:

Переадресация

Самый популярный комментарий по услугам был: «неудобная настройка переадресации». И мы это исправили. Добавили кнопку на главной странице для быстрого перехода в настройки переадресации, так что блуждать по всему кабинету в ее поисках теперь не нужно.

Быстрая кнопка переадресации:

Переадресация быстро включается-отключается, ее можно настроить самостоятельно для конкретных линий или сразу со всех номеров. Можно включать переадресацию для звонков, не получивших ответа в течение какого-то времени (например, никто не снимает трубку 5 секунд). Раньше такие настройки, пожалуй, могла задать только наша техподдержка, а сегодня на такие изменения клиент потратит не больше 2 минут.

Окно настройки проектировали по комментариям техподдержки:

Вход в АТС

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

Саму АТС мы, кстати, тоже обновили:

Финансы

Платежи

В главном меню появилась яркая кнопка «Пополнить счет». С помощью одного клика можно перейти к выбору способа оплаты: банковская карта, Яндекс.Деньги, Альфа-Клик или другой способ.

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

«Каждой системе оплаты прикрепите соответствующую иконку!» — говорили они. «Прикрепили!» — говорим мы.

Добавили всплывающие напоминания о балансе в интерфейс, а настройку уведомлений вынесли в отдельный пункт в разделе Финансы (об этом тоже многие просили).

Настройка уведомлений об отключении за неуплату:

Расходы и статистика

В разделе статистики пользователи получили возможность настраивать отчеты.

«Добавьте, пожалуйста, параметры сортировки в таблице показа статистики по столбцам: Назначение (сортировать по номерам), Длительность (по возрастанию/убыванию)»

В отчетах выбирается период, вид отчета, номера линий, направление звонков, источник и назначение. Столбцы со значениями сортируются. До 40 000 записей скачиваются за раз. Что и говорить, фильтрация в статистике улучшилась на порядок.

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

Еще одно нововведение: статус по каждой линии, активна она или нет. Многие клиенты также просили это отображать. Пожалуй, из множества таких деталей и складывается удобный интерфейс.

Документы

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

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

Подведем итоги

Было ли правильным решением делать все самим? Это оказалось долго и сложно. Зато надежно и качественно. Правильно ли было всех клиентов поставить перед фактом обновления кабинета? Рискованно. Зато мы получили мгновенный фидбек и по горячим следам внесли изменения.

Наш личный кабинет стал таким, каким получился. Факт: новый интерфейс уже выполняет 90% пожеланий пользователей. И это, пожалуй, главное. Подтверждение — опрос лояльности за сентябрь-ноябрь 2016 года.

В данном опросе 0 — никогда не порекомендую, 10 — обязательно порекомендую:

Результат, как говорится, налицо. Впереди еще много работы (единый кабинет с управлением виртуальной АТС и полная версия для мобильных устройств), но начало положено – основные изменения завершены. И вполне успешно.
ссылка на оригинал статьи https://habrahabr.ru/post/316532/

IIS Request filtering против ddos-атаки

Лежим

Заказчик, чьи сайты я поддерживал ранее, обратился с тем, что сайт лежит и отдает 500 ошибку. У него стандартный сайт на ASP.NET WebForms, не скажу, что очень нагруженный, но бывали проблемы с производительностью базы данных (MS SQL Server на отдельном сервере). Недавно сервер БД поменяли и перенесли данные.
Этот сайт не основной бизнес заказчика, поэтому практически не обслуживался. У него не настроено никакого мониторинга  и сбора метрик и вообще за ним особо не следят.

Данные телеметрии

Какие аномалии бросились в глаза:

  1. Процесс w3wp использовал более 50% CPU (обычно сильно меньше).
  2. Количество потоков в этом процесс стабильно прирастало (сайт не успевал обслужить клиентов).
  3. Диск на сервере БД использовался на 100% (Active Time).
  4. Длина очереди обращений к диску с базами проекта была большой (обычно в районе нуля-единиц).
  5. Оперативная память на сервер БД использована полностью.
  6. Профайлер показал, что есть один горячий метод, который ходит в БД.

Тюнинг СУБД

Первая моя гипотеза была связана с неполадками на стороне сервера БД из-за его переноса: забыли что-то настроить, не отрабатывает джоб по сбору статистики и перестроению индекса и т.п.
Память — сразу стало ясно, что при переносе СУБД забыли ограничить использование оперативной памяти  на новом сервере — ограничиваем. По прошлому опыту этой конфигурации вполне хватало 24гб (из общих 32).
Проверям джобы — все норм. Запускаем Tuning Advisor и достраиваем недостающие индексы (среди них был и индекс для горячего запроса из профайлера).
Выхлоп близок к нулю: сайт лежит.

IIS

Захожу в логи и сразу все становится понятно — DDoS:

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

В логах видим около 200 запросов в секунду (обычные пользователи генерят до десяти в минуту по метрике).
Все запросы с разных IP, объединяет их только схожий user-agent:

GET 101.200.177.82 WordPress/4.2.2; www.renwenqifei.com;+verifying+pingback+from+37.1.211.155 503
GET 54.69.1.242 WordPress/4.2.10; 54.69.1.242;+verifying+pingback+from+37.1.211.155 503
GET 123.57.33.117 WordPress/4.0; www.phenomenon.net.cn;+verifying+pingback+from+37.1.211.155 503
GET 54.69.236.133 WordPress/4.3.1;+http://www.the-call-button.com;+verifying+pingback+from+37.1.211.155 503
GET 52.19.227.86 WordPress/4.3.6; 52.19.227.86;+verifying+pingback+from+37.1.211.155 503
GET 52.27.233.237 WordPress/4.1.13; 52.27.233.237; verifying+pingback+from+37.1.211.155 503
GET 202.244.241.54 WordPress/3.5.1; www.fm.geidai.ac.jp 503
GET 52.34.12.105 WordPress/4.3.6; 52.34.12.105; verifying+pingback+from+37.1.211.155 503
GET 128.199.195.155 WordPress/4.3.6; www.glamasia.com;+verifying+pingback+from+37.1.211.155 503
GET 61.194.65.94 WordPress/4.2.10; wpwewill.help;+verifying+pingback+from+37.1.211.155 503
GET 23.226.237.2 WordPress/4.3.1; hypergridder.com;+verifying+pingback+from+37.1.211.155 503
GET 104.239.228.203 WordPress/4.2.5; pjtpartners.com;+verifying+pingback+from+37.1.211.155 503
GET 104.239.168.88 WordPress/4.2.10; creatorinitiative.com;+verifying+pingback+from+37.1.211.155 503
GET 166.78.66.195 WordPress/3.6; remote.wisys.com/website 503
GET 212.34.236.214 WordPress/3.5.1; nuevavista.am 503

Это известный тип атаки: WordPress сайт с включенным Pingback (включен по умолчанию), может использоваться в DDOS-атаке на другие сайты. Более подробная статья на Хабре.

Настраиваем фильтр запросов

Есть несколько уровней где можно фильтровать запросы. Первый — это файрвол. Грепаем ip — добавляем их в файрволл, по расписанию собираем вновь появившиеся. Плюсы — отличная скорость, нет мусорных запросов в логах. Минусы — надо писать скрипты и следить.
Второй уровень — сам IIS (из явных минусов — мусорные запросы попадают в логи). Третий уровень — написать модуль и использовать его. Это самый гибкий подход, но трудоемкий и имеет невысокую производительность.
Я остановился на втором уровне из соображений получить решение совершив минимум действий.
У IIS много возможностей по фильтрации запросов. В данном случае подходит Request Filtering. Более подробно об установке и настройке.
Выбираем сайт -> Request Filtering ->Rules -> Add filtering rules

И указываем, что мы хотим отфильтровать все запросы где в Header: User-Agent есть слово WordPress.

Или можно указать соответствующие настройки в файле web.config

<system.webServer>     <security>         <requestFiltering>             <filteringRules>                 <filteringRule name="ddos" scanUrl="false" scanQueryString="false">                     <scanHeaders>                         <clear />                         <add requestHeader="User-Agent" />                     </scanHeaders>                     <denyStrings>                         <clear />                         <add string="WordPress" />                     </denyStrings>                 </filteringRule>             </filteringRules>         </requestFiltering>     </security> </system.webServer>

Сразу после применения этого фильтра сайт заработал. Все показатели вернулись к норме. Если бы я сразу проверил логи — на все ушло бы менее получаса.

Что еще умеет IIS?

IIS — очень крутой и производительный сервер для веб-приложений. Помимо передачи запроса в управляемую среду он много что умеет делать и по производительности сильно обыгрывает managed-решения.
В разделе Request Filtering вы можете настроить еще много различных фильтров: по методам, сегментам урла, query-параметрам, расширению и т.д. Можно запретить в asp.net проекте специфичные для PHP query-параметры (попытка получить доступ к htaccess или файлу с паролями). Можно запретить злонамеренные запросы, например, содержащие sql-инъекции. Это делается не как защита от этих атак, а в целях экономии ресурса сервера: IIS самостоятельно откинет эти запросы и сделает это быстро с минимальными затратами памяти и процессорного времени.
Еще один механизм называется IP Address and Domain Restrictions. Этот механизм позволяет составлять белые и черные списки IP-адресов для ограничения доступа к сайту. Вы можете заблокировать злобного парсера или наоборот открыть доступ на тестовый сайт или админку только с определенных IP. Более подробно читать в официальной документации.
И третий механизм, который может вам помочь противодействовать ддос-атакам и нежелательным парсерам — Dynamic IP Address Restrictions. 
Не всегда мы можем следить за постоянно меняющимися ip-адресами злоумышленника. Но с помощью этого инструмента мы можем ограничить частоту запросов. Таким образом, IIS на аномально большое количество запросов с одного IP-адреса будет быстро отдавать 403 или 404. Будьте аккуратнее с поисковыми ботами. Официальная документация.

Выводы

Не отключайте логи, настраивайте мониторинг, который явно вас предупредит об аномалиях в показателях. Это можно сделать быстро и недорого, и сэкономит вам время при расследованиях инцидентов. Настройку мониторинга, а также административные и организационные меры противодействия оставим за рамками этой статьи.
ссылка на оригинал статьи https://habrahabr.ru/post/316550/

Как работают ИТ-специалисты. Даниил Пивоваров, Vscale

image

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

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

Сегодня наш гость — Даниил Пивоваров из Vscale. Он жалеет о недостаточном техническом бекграунде, а также видит способ повышения эффективности в верно подобранной периодичности отдыха.

Чем занимаетесь в компании?

Руковожу проектом vscale.io. Занимаюсь планированием разработки, управляю roadmap’ом, экономикой продукта. Много взаимодействую с маркетингом и саппортом.

Одно слово (словосочетание) лучше всего описывающее как вы работаете:

Лучше словосочетанием: много и с кайфом.

Сколько часов в сутки вы уделяете работе?

В среднем, наверное, от 10 до 15.

Сколько часов вы спите?

6-8 часов.

Что еще делаете по пути на/с работы? Много времени уходит на дорогу?

Раньше жил в часе езды на метро и около двух часов на машине, в основном читал (если на метро).

К счастью, сейчас я живу в 20-ти минутах езды на машине от офиса. Это очень круто, хотя уже и не почитать.

Каким to do менеджером пользуетесь лично вы?

Google Keep.

Каким таск-менеджером / issue-tracker’ом / репозиторием пользуетесь?

JIRA, GitLab.

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

Для меня незаменимы Google Docs, draw.io.
Постоянно работаю в Confluence.

В качестве IDE — продукты JetBrains: PyCharm, DataGrip. Ну и Vim, конечно. Без него никуда.

Есть ли в вашем отделе какие-то внутренние проекты, библиотеки и для чего они создавались?

У нас в Selectel есть собственная time series database. Насколько мне известно создавался для внутренних задач, сейчас это – open source проект.

Также, когда-то коллеги делали клиент для VNC, как альтернативу, популярному NoVNC. Его использует, например, Open Source панель для управления серверами — Ajenti.

На самом деле внутренних библиотек достаточно много. Если есть понимание, что мы сделали что-то, что решает нашу проблему и может пригодиться сообществу — это обязательно попадет в наш github.

Что вас раздражает больше всего, когда вы работаете?

Уговоры. Терпеть не могу уговаривать поработать, хотя и себя иногда приходится.

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

Исходя из моей специфики работы, наверное, это Адизес: «Идеальный руководитель», «Жизненный цикл корпораций».

Очень, и далеко не только в работе, помогает теория Афанасьева о психейоге. Она раскрывается в работе под названием «Синтаксис любви». Ее мне порекомендовал мой наставник на заре становления моего интереса к менеджменту и, с тех пор, это мой хендбук.

Что предпочитаете: электронные читалки или бумажные книги?

К сожалению, электронные читалки. Они удобнее.

Какую технику (компьютеры, планшеты, смартфоны) и операционные системы вы предпочитаете на работе и дома?

Долгое время все было на Linux и Android, но сейчас полностью перешел на экосистему Apple, и мне это нравится.

Вы слушаете музыку, когда работаете?

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

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

Какой лайфхак позволяет вам быть эффективнее?

Стараюсь отдыхать каждый квартал по 3-4 дня, один раз в год — неделю, один раз — 2. Нужно уметь вовремя абстрагироваться и дать себе передышку. К сожалению, не всегда получается соблюдать такой режим и это заметно сказывается на моем эмоциональном фоне и возможностях концентрации. Однако, если все-таки удается дать себе отдых — эффективность на некоторые время может превысить свои 100%.

Без каких приложений и сервисов не можете обойтись ни в работе, ни в личной жизни?

Google inBox, Календарь.

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

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

Что бы вы порекомендовали человеку, пытающемуся пройти тот же путь?

Придумывайте себе задачи, решайте их с удовольствием. Ищите это удовольствие в том, чем занимаетесь. Без него стать действительно крутым специалистом невозможно.
ссылка на оригинал статьи https://habrahabr.ru/post/316512/

Два аспекта «децентрализованных» одностраничных приложений

В статье мы попытаемся описать два совершенно не связанных с собой аспекта децентрализованных одностраничных приложений. Это соединение двух пользователей и сохранение паролей в одностраничном приложении при помощи браузера.

Информация об используемой технологии WebRTC — webrtc.org. В браузере весь смысл общения завязан на этой технологии, а точнее на WebRTC API которое доступно для Front-end разработчика.

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

  • Генерация уникальных id для идентификации подключенных устройств (девайсов)
  • Обмен SDP (session description protocol) для инициализации соединения Клиент — Клиент; для сигнализации клиентам использовался websocket протокол

Создание соединения

Рассмотрим детально схему соединения для двух пользователей. Для этого выделим основные шаги в обычной схеме соединения Клиента А и Клиента Б:

  1. Клиент А является инициатором соединения и генерирует предложение (Offer), т.е sdp-предложение, которое содержит все доступные кодеки, на которых может общаться клиент и другую информацию. Клиент А отправляет свое sdp-предложение Клиенту Б.
  2. Клиент Б принимает sdp-предложение и генерирует ответ (Answer), т.е sdp-ответ. На данном этапе Клиент Б генерирует у себя все доступные кодеки и выбирает те, которые доступны обоим клиентам, добавляет свою информацию и отправляет его Клиенту А.
  3. Клиент А получает sdp-ответ от Клиента Б. Далее Клиент А уже напрямую связывается с Клиентом Б на основе полученного ответа и информации в нём. После этого между ними образовался RTCDataChannel — канал обмена данными.

Выделенные слова в трех случаях как раз показывают зачем нужен сервер на начальном этапе соединения. Для обмена данными через сервер.

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

Ниже представлена схема соединения двух инициирующих/принимающих клиентов.

  1. Одновременно оба клиента получают оповещение по вебсокет-соединению о том, что они в одном чате. Клиент А и Клиент Б инициируют соединение — каждый генерирует своё sdp-предложение и отсылает его на сервер.
  2. Сервер в свою очередь отправляет полученные предложения адресатам (предложение от Клиента А отправляет Клиенту Б, предложение от Клиента Б отправляет Клиенту А).
  3. Каждый клиент после получения sdp-предложения генерирует sdp-ответ на него. Оба клиента посылают свои sdp-ответы на сервер.
  4. Сервер в свою очередь отправляет полученные sdp-ответы их адресатам (ответ от Клиента А отправляет Клиенту Б, ответ от Клиента Б отправляет Клиенту А).
  5. Каждый клиент получает sdp-ответ и принимает его. Важное условие что у каждого клиента есть логика, что с каждым другим клиентом не может быть более одного соединения. Соответственно, если у Клиента Б есть открытый RTCDataChannel с Клиентом А, то он не создает новый RTCDataChannel с ним, можно сказать, все остальное просто игнорируется. Таким образом то соединение, которое создастся быстрее и выиграет.

Таким образом при инициировании соединения двумя клиентами, между ними будет всего один RTCDataChannel, а не два.

Регистрация пользователя и Browser History

При работы с приложением каждый пользователь проходит следующие этапы:

  1. Регистрация — для каждого нового пользователя.
  2. Авторизация — для каждого ранее зарегистрированного пользователя.
  3. Непосредственно работа с чатом.

Для этого в приложении были предусмотрены три страницы, каждая из которых предназначена для соответствующего этапа (структура сайта):

  • /register — страница регистрации
  • /login — страница логина
  • /chat — страница чата

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

В нашем случае, введенные данные пользователя должны предлагаться к сохранению для формы логина при смене url с "/login" на "/chat", а при смене "/login" на "/register" не должны предлагаться. На практике это оказалось невозможно реализовать. Сохранение предлагалось и при переходе с "/login" на "/register" и с "/register" на "/login". Таким образом задача заключалась в отмене сохранения данных в браузере для определенных случаев.

Для решения данного вопроса были использованы различные методы, которые представлены ниже.

Автозаполнение для формы

Чтобы отключить автозаполнение на странице регистрации, устанавливаем для всей формы атрибут ‘autocomplete’ со значением ‘off’.

Разметка для данного варианта:

<form autocomplete="off" data-role="loginForm">         <label>Имя пользователя:</label> 	<input type="text" name="userName"> 	<label>Пароль пользователя:</label> 	<input type="password" name="userPassword"> 	<button type="submit">Войти</button> </form>

Ссылка на данный вариант решения stackoverflow.com/a/468295.

Автозаполнение для конкретных полей

Пробовали отключить автозаполнение на странице регистрации установив атрибут ‘autocomplete’ со значением ‘off’ для полей input, то есть имени и пароля пользователя.

Разметка для данного варианта:

<form data-role="loginForm"> 	<label>Имя пользователя:</label> 	<input type="text" name="userName" autocomplete="off"> 	<label>Пароль пользователя:</label> 	<input type="password" name="userPassword" autocomplete="off"> 	<button type="submit">Войти</button> </form>

В предыдущей ссылке обсуждается и этот вариант.

Скрытие полей

Данный вариант предполагает добавление в разметку скрытого элемента div, который включает в себя поля имени и пароля пользователя, которые всегда будут оставаться пустыми. Разметка для данного варианта:

<form data-role="loginForm"> 	<div style={{display:'none'}}> 		<input  type="text" /> 		<input type="password" /> 	</div> 	<label>Имя пользователя:</label> 	<input type="text" name="userName" autocomplete="off"> 	<label>Пароль пользователя:</label> 	<input type="password" name="userPassword" autocomplete="off"> 	<button type="submit">Войти</button> </form>

Ссылка на данный вариант решения stackoverflow.com/a/25111774. Аналогичное решение предложено и в данном источнике.

Обнуление полей при submit

В данном варианте прибегаем к помощи js. При клике пользователя на кнопку «Войти» по событию submit выполняем обнуление полей имени и пароля.

Программный код:

  handleSubmit: function(event) {     this.loginForm = document.querySelector('[data-role="loginForm"]');     event.preventDefault();     this.loginForm.elements.userName.value = '';     this.loginForm.elements.userPassword.value = '';     }

Обнуление данных выполнялось как сразу после клика, так и через некоторый интервал времени ( SetTimeout() ).

Программный переход через HistoryAPI

Последний из вариантов заключается в создании новой кнопки в форме, которая бы выполняла роль кнопки submit.

Разметка данного варианта:

<form data-role="loginForm"> 	<label>Имя пользователя:</label> 	<input type="text" name="userName" autocomplete="off"> 	<label>Пароль пользователя:</label> 	<input type="password" name="userPassword" autocomplete="off"> 	<button type="button" data-action="submit" onclick="handleClick">Войти</button> </form>

Программный код:

handleClick(event) { 	if (event.target.dataset.action === 'submit'){              history.pushState({foo: 'bar'}, 'Title', '/chat') 	}   }

Все вышеприведенные способы не позволяли при одном переходе сохранять пароль, а при другом не сохранять. Можно было либо сохранять всегда, либо не сохранять никогда.

Отсюда конечно о наболевшем, что давно пора для одностраничных приложений сделать JS API для браузера о сохранении пароля:

window.navigator.promtPasswordSave()

Что-то вроде этого было бы замечательно.

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

  • /account — страница регистрации и логина
  • /chat — страница чата

Где страница /account имеет два внутренних состояния login и register, в зависимости от этого состояния мы и генерируем ту или иную разметку. Только так мы смогли решить проблему с контролируемым сохранением пароля в браузере.

SPACHAT (Single Page Application Chat) — веб приложение для обмена сообщениями между клиентами с помощью технологии WebRTC, которое мы и реализовываем. Реализованное приложение или просто чат можно посмотреть на сайте spachat.net.

Непосредственно сам код доступны по ссылке github.com/volodalexey/spachat.
ссылка на оригинал статьи https://habrahabr.ru/post/316556/

2.5F Аутентификация

Привет, привет!
Поздравляю всех причастных с днем ИБэшника =)
Хочу поделиться опытом по настройке 2.5 факторной аутентификации удаленных пользователей. Почему 2.5, думаю, вы поймете из содержания, если считать модель «1. Что знаю. 2. Что имею. 3. Кем являюсь» эталонной. Если заинтересовало, прошу!

Что нужно сделать попытался нарисовать на схеме:

Вкратце: удаленный пользователь имеет eToken (Alladin), учетку в Active Directory, входящую в определенную группу и одноразовый пароль из мобильного приложения Google Authenticator. Ему нужно успешно подключиться к некоторому сервису.
На хабре есть статья, в которой описаны основные моменты по настройке CISCO ASA, AnyConnect, Google Auth и Freeradius. Дублировать смысла не вижу, все практически так, за исключением следующего.
Рекомендую установить утилиты RADIUS сервера для тестирования командой radtest и дебага radiusd -X

yum install freeradius freeradius-utils

Из опыта появлявшихся ошибок, мне было бы удобнее настраивать в следующем порядке:

  1. RADIUS
  2. Google
  3. SSSD
  4. PAM
  5. CISCO

Но как обычно не все так просто и по порядку.
На github нужные нам компоненты Google лежат тут «The pluggable authentication module (PAM) is in a separate project.» При установке могут возникнуть различного рода ошибки, тут надо читать и доустанавливать, если необходимо инструменты разработчиков и библиотеки (gcc, libqrencode и т.п.).

Теперь, что не вышло (может и вышло, но он решил не писать об этом) у автора статьи, приведенной выше.
Для возможности использования учетных записей из AD необходимо установить SSSD и компоненты.

yum install sssd realmd adcli

Далее добавляем RADIUS сервер в домен

realm join ваш_домен

Разрешаем доступ пользователям из заранее опреденной группы в AD

realm permit -g ваша_группа_из_AD

На данном этапе может возникнуть проблема с именем домена (.ru, .net, .test и т.п.) Записи 1 уровня могут не определяться, соответственно имя вашего домена может быть неполным, это повлияет на процесс аутентификации и конфигурацию RADIUS сервера.
В моем случае это выглядело так username@domain, где domain это только имя 2 уровня. К чему это может привезти? Вы просто не сможете успешно аутентифицироваться, если не закомментировать следующие строки в файле /etc/raddb/policy.d/filter

#	if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\\.(.+)$/))  { #		update reply { #Reply-Message += "Rejected: Realm does not have at least one dot separator" #		} #		reject #	}

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

su – domain_user@domain google-authenticator

Этот пользователь должен быть членом группы, которую мы указали выше командой realm permit.
На этом этапе тоже возникают проблемы, механизмы безопасности не дадут создать домашнюю директорию для нового пользователя. Эта директория необходима для файла ~google-authenticator, в котором содержится информация с кодами верификации и ключом для каждого пользователя.
Чтобы это исправить необходимо компонент SELinux перевезти в разрешительный режим:

setenforce permissive

Далее нужно перейти в /etc/pam.d/radiusd и записать следующий конфиг:

#%PAM-1.0 auth       requisite    pam_google_authenticator.so forward_pass auth       required     pam_sss.so use_first_pass account    required     pam_nologin.so account    include      password-auth session    include      password-auth

Не забудьте про NTP и синхронизируйте время, иначе одноразовые пароли работать не будут, а в файле /var/log/secure будет сообщение «invalid code»

Когда все готово можно протестировать:

  1. После запуска AnyConnect появится окно eToken PKI Client
  2. Выбираем свой сертификат. Вводим пароль от контейнера — 1 фактор
  3. Далее вводим учетные данные пользователя AD (логин+пароль) — 2 фактор
  4. Добавляем к паролю код из приложения на телефоне (без пробелов) — 0.5 фактор

2.5 факторная аутентификация готова.
Если я что-то забыл и у вас не завелось, пишите в комментариях, постараюсь помочь =)
ссылка на оригинал статьи https://habrahabr.ru/post/316546/