Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

До появления HTML5 единственное, что мы не могли контролировать и управлять (без перезагрузки контента или хаков с location.hash) — это история одного таба. С появлением HTML5 history API все изменилось — теперь мы можем гулять по истории (раньше тоже могли), добавлять элементы в историю, реагировать на переходы по истории и другие полезности. В этой статье мы рассмотрим HTML5 History API и напишем простой пример, иллюстрирующий его возможности.

Основные понятия и синтаксис

History API опирается на один DOM интерфейс — объект History. Каждый таб имеет уникальный объект History, который находится в window.history. History имеет несколько методов, событий и свойств, которыми мы можем управлять из JavaScript. Каждая страница таба(Document object) представляет собой объект коллекции History. Каждый элемент истории состоит из URL и/или объекта состояния (state object), может иметь заголовок (title), Document object, данные форм, позиция скролла и другую информацию, связанную со страницей.

Основные методы объекта History:

1. window.history.length: Количество записей в текущей сессии истории
2. window.history.state: Возвращает текущий объект истории
3. window.history.go(n): Метод, позволяющий гулять по истории. В качестве аргумента передается смещение, относительно текущей позиции. Если передан 0, то будет обновлена текущая страница. Если индекс выходит за пределы истории, то ничего не произойдет.
4. window.history.back(): Метод, идентичный вызову go(-1)
5. window.history.forward(): Метод, идентичный вызову go(1)
6. window.history.pushState(data, title [, url]): Добавляет элемент истории.
7. window.history.replaceState(data, title [, url]): Обновляет текущий элемент истории

Роботизация и автоматизация становятся всё востребованнее, и многим хотелось бы научиться создавать подобные системы и устройства. Но с чего начать, как освоить азы? Мы сделали для вас небольшую подборку русскоязычных и англоязычных YouTube-каналов с учебными материалами и методическими пособиями по робототехнике.

Мы всё-таки смогли дойти до третьей части и добрались до самого интересного — организации асинхронных вычислений.

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

Теперь посмотрим, как можно управлять потоком исполнения (control flow) в случае обработки асинхронных задач.

• Параллелизм (часть 1)
  
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2)
  
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3, текущая)
  
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

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

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

В этой мы посмотрим на ещё две модели, одна из которых не делает такого вида, а вторая смотрит на конкурентные вычисления с более абстрактной стороны.

• Параллелизм (часть 1)
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2, текущая)
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3)
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

Джентльменский набор терминов

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

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

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

Этот блог выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий запрос.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


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


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

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

Поехать работать в Австралию или Таиланд, когда тебе 25 и нет семьи, не так и сложно. И таких историй большое количество. А вот переехать, когда тебе под 40, жена и трое детей (8 лет, 5 лет и 2 года) — задача другого уровня сложности. Поэтому хочу поделиться своим опытом переезда в Германию.

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

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

Лонгрид варнинг: вас предупредили, много букв.

Уже давно ведётся разработка формата дистрибуции приложений, которые были "свободны" от общесистемных зависимостей. Ubuntu очень, очень активно продвигает свой snap, gnome — flatpack. Оба обещают рай и свободу от rpm/deb. Давайте же подумаем про проблему, которую они хотят решить, и цену, которую они просят за решение этой проблемы.

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

Но рассказать я бы хотел не про это, а про то, как работает бэк-офис до рейса.

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

Зовите детишек! Сейчас дядя Андрей расскажет рождественскую страшилку об NTP (Network Time Protocol).

Почти два года назад, в понедельник 16 января 2017 года, в нашу систему баг-репортов BitFolk поступил интересный тикет от постороннего лица. Отправитель представился как ведущий инженер-программист компании NetThings UK Ltd.

Тема: запрос NTP на IP 85.119.80.232

Привет,

Это может показаться странным, но мне нужно настроить сервер NTP по IP-адресу 85.119.80.232.

Что такого особенного в адресе 85.119.80.232? Это IP-адрес одного из NTP-серверов для обслуживания наших клиентов. За несколько недель до этого тикета сервер также был частью проекта NTP Pool.

Здесь важное слово «был». В конце декабря 2016 года я вывел NTP-серверы BitFolk из общественного пула и заблокировал их для посторонних.

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

Диабет 1 типа – заболевание неприятное, обычно атакующее жертву в раннем возрасте, и превращающее каждый день в последовательность медицинских процедур – подсчёт правильного количества инсулина для использования с каждым кусочком еды, работа с неизбежными высокими и низкими уровнями глюкозы, и постоянные уколы для проверки крови. Непрерывный мониторинг глюкозы (НМГ) стал манной небесной для миллионов семей диабетиков, поскольку он даёт нам возможность разрешать нашим детям быть детьми, отпускать их с ночёвкой и разрешать съесть ещё один кусочек пиццы, не превращая это в научный проект. Кроме того, хороший контроль глюкозы означает уменьшение вероятности наступления опасных последствий диабета в зрелом возрасте – слепота, болезни сердца, ампутации. Кроме того, довольно круто, что у меня есть телеметрия для моего ребёнка – мы зовём её «наш киберребёнок».

Для некоторых оптимизаций требуются сложные структуры данных и тысячи строк кода. В других же случаях серьёзный прирост производительности даёт минимальное изменение: иногда нужно лишь поставить ноль. Это похоже на старую байку о котельщике, который знает правильное место для удара молотком, а потом выставляет клиенту счёт: $0,50 за удар по клапану и $999,50 за знание, куда бить.

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

Intel разработала чип 8087 в 1980 году для того, чтобы улучшить производительность ПК с процессорами линеек 8086/8088 (таких, как IBM PC) при выполнении операций с плавающей запятой. Поскольку первые микропроцессоры были предназначены для выполнения операций с целыми числами, выполнение операций с числами с плавающей запятой было медленным, что уже и говорить о выполнение трансцендентных операций, таких как тригонометрические функции или логарифмы. Сопроцессор 8087 значительно повысил скорость выполнения задач с плавающей запятой, все выполнялось почти в 100 раз быстрее. Архитектура 8087 была реализована и в более поздние процессоры Intel, а инструкции 8087 по-прежнему используются в современных x86 ПК. Intel представила в 1980 году чип 8087, предназначенный для улучшения производительности вычислений с плавающей запятой на процессорах 8086 и 8088.

Расшифровка выступления на конференции Web Camp Zagreb Мачея Цегловского, американского веб-разработчика, предпринимателя, докладчика и социального критика польского происхождения.

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

Опасение было оправданным. Азот, из которого состоит большая часть атмосферы, энергетически нестабилен. Если столкнуть два атома достаточно сильно, они превратятся в атом магния, альфа-частицу и выпустят огромную энергию:

N¹⁴ + N¹⁴ ⇒ Mg²⁴ + α + 17,7 МэВ

Жизненно важным вопросом было то, может ли эта реакция стать самоподдерживающейся. Температура внутри шара ядерного взрыва должна была превысить всё, что когда-то наблюдалось на Земле. Не получится ли, что мы бросим спичку в кучу сухих листьев?

Тема latency со временем становится интересной в разных системах в Яндексе и не только. Происходит это по мере того, как в этих системах появляются какие-либо гарантии по обслуживанию. Очевидно, дело в том, что важно не только пообещать какую-то возможность пользователям, но и гарантировать её получение с разумным временем отклика. «Разумность» времени отклика, конечно, сильно различается для разных систем, но базовые принципы, по которым во всех системах проявляется латентность, — общие, и их вполне можно рассматривать в отрыве от конкретики.

Меня зовут Сергей Трифонов, я работаю в команде Real-Time Map Reduce в Яндексе. Мы разрабатываем платформу для обработки потока данных в реальном времени с секундным и субсекундным временем отклика. Платформа доступна для внутренних пользователей и позволяет им выполнять прикладной код над постоянно поступающими потоками данных. Я попытаюсь сделать краткий обзор основных концепций человечества на тему анализа latency за последние сто десять лет, и сейчас мы попробуем понять, что именно про latency можно узнать, применяя теорию массового обслуживания.

Однажды в моей команде был настолько слабый парень, что его собирались уволить (уволить разработчика!). Каждый мой коммент на ревью к его коду был гвоздем в крышку гроба. Я почти слышал стук молотка, нажимая «submit review». Он был приятным человеком, я даже переживал за него, но это не мешало мне разносить его старания в щепки. Мое право критиковать его работу казалось очевидным и неотъемлемым. Все просто — я сильнее, я прав. Никто же не хочет сказать, что плохой код — это хорошо, а? Его уволили, предварительно лишая стандартной премии в течение нескольких месяцев.

Я говорил себе: «Но ведь не делать же мне всю работу за него!? Он занимал место более талантливого разработчика. Я все правильно сделал». Но почему-то на душе скребли кошки. И когда мне пришел на ревью очередной pull request, что-то очень сильно поменялось.

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

Так какого же чёрта моё прекрасное IT превращается в детский сад «Весёлый Програм-Мишка»?

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


Папа, а почему ты смотришь в телефон?

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