#продолжи_мысль_SE


Рецензия на пост «IAA: Идентификация, Аутентификация, Авторизация» (автор: Татьяна Бушева): ясно, коротко, доступно. Но кавычки я бы поправил (душным голосом)

О чем пост

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

Почему меня он зацепил

Потому что здесь одновременно рассматриваются:

- идентификация,
- аутентификация,
- авторизация.

Часто бывает так, что при рассмотрении этой темы про идентификацию почему-то забывают. А Татьяна не забыла — плюс в карму.

Подача, ясность объяснения и т.д.

Понравилась подача и объяснение с использованием аналогий. Еще и примеры из реальной жизни есть: пример, как IAA используется и даже пример того, как оформить это все в ТЗ.
Прямо бери и пользуйся — я такое люблю.
Не понять объясняемые в посте вещи после такого просто невозможно.

В общем, полнейший рекомендасьён. Читаем, наслаждаемся и берем на вооружение.

А теперь чуть-чуть подушню

Зацепился глаз за оформление. Пример:

...("Тебе можно в переговорку, но не в серверную»)...

— кавычки-лапки и кавычки-елочки «в одной упряжке».

Можно было бы промолчать об этом, но профдеформация (чтоб её)…

Участвую в конкурсе «Продолжи мысль» от @systems_education.

#продолжи_мысль_SE


Рецензия на пост «Фронт раньше бэка – это вообще законно?» (автор: Сергей Сапрыкин), который наглядно показывает, как НЕ НАДО выстраивать процессы в IT


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

Чем полезен пост

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

Что смутило в посте

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

Какие выводы можно сделать

Вывод один. Как сказал один умный человек (правда, не знаю, кто это был): «Не делайте плохо, делайте хорошо».


Участвую в конкурсе «Продолжи мысль» от @systems_education

- 50+ докладов и мастер-классов,
- 2 дня профессионального общения с 400+ участниками из сотен компаний СНГ,
- полезные инсайты и новые знания.

Все это — международная конференция для технических писателей TechWriter Days 3 , которая пройдет 27-28 марта в Москве.

Мероприятие состоится в гибридном формате — офлайн + онлайн-трансляция.

📚А до 1 сентября можно стать докладчиком. Для подачи заявки на выступление переходите по ссылке. Больше информации для докладчиков вы найдёте здесь

#tw_api_jekyll

Всем привет.
Продолжаем работу над сайтом-справочником API на базе Jekyll. В прошлый раз мы вывели на сайт эндпоинты, их краткое (summary) и более развернутое (description) описание, добавили меню слева для навигации по странице, а также некоторые стили.

В этот раз сделаем следующее:

- Выведем на страницу параметры (те, которые в query, path, header или cookie) и отобразим их в виде таблицы. Пока с оговоркой: выведем параметры, которые сразу описаны в объекте в описании эндпоинта. Они еще могут «подтягиваться» по ссылке: рендеринг такого варианта реализуем позже, когда будем рендерить на странице компоненты (Components).
- Сделаем фиксацию, раздельный скролл для меню слева и «основного» содержимого сайта.
- Добавим больше стилей, чтобы сайт стал выглядеть чуть более привлекательно.

Вывод параметров на страницу

Для вывода параметров в файл api_reference.liquid был добавлен фрагмент между {% if operation.parameters %} <div class="api-paths__parameters"> и </div>{% endif %}.
Внутри фрагмента реализован цикл, который проходится по массиву параметров (если он есть в обрабатываемом эндпоинте) и рендерит их в виде таблицы.
Также в файл /assets/css/style.css добавлены стили для таблицы, для классов (ищите по классу .parameters-table).

Раздельный скролл для меню слева и «основного» содержимого сайта

Чтобы сделать раздельный скролл для меню и «основного» содержимого, в файл /assets/css/style.css были добавлены стили для класса .schema-toc_paths:

.schema-toc_paths {
    /* Обеспечивают неподвижность содержимого при скролле основного контента */
    position: sticky;
    top: 0;
    /* Отображает меню поверх других элементов */
    z-index: 10;
    /* Задает цвет фона для меню */
    background-color: #f5eff5;
    /* Задаёт высоту элемента равной 100% высоты видимой области окна браузера */
    height: 100vh;
    /* Отключает горизонтальную прокрутку. В будущем, возможно, изменим этот стиль, чтобы избежать «расползания» колонки меню из-за длинных путей в энпоинтах */
    overflow-x: hidden;
    /* Включает вертикальную при необходимости: если количество элементов в меню не помещается в видимую область окна браузера */
    overflow-y: auto;
}

Добавление новых стилей

Стилей добавлено не очень много (в файле /assets/css/style.css). Отметить из этого всего можно следующие:

1. Сброс и замена стандартных стилей ссылок по всему документу (подчеркивание, цвета и пр.):

a {
    text-decoration: none;
    color: rgb(72, 71, 71);
}

2. Цвет фона, шрифта и закругление для HTTP-глаголов (POST, GET, PUT, PATCH, DELETE) эндпоинтов в меню и в основном контенте:

... {
    background-color: <код цвета>
    color: white;
    padding: 1px 10px 1px 10px;
    border-radius: 10px;
}

Свойства заданы для классов .schema-toc_prefix-get, .schema-toc_prefix-post, .schema-toc_prefix-patch, .schema-toc_prefix-delete, .schema-toc_prefix-put.

3. Чуть более симпатичное отображение путей (название) эндпоинтов в основной секции сайта:

.api-paths_path {
    font-size: 1.5em;
    font-weight: bold;
    margin-bottom: 15px;
    opacity: 90%;
}

Готово. Если вы все сделали правильно, ЕЩЕ БОЛЬШЕ содержимого спецификации появится на странице сайта по сравнению с предыдущим этапом. И это будет выглядеть уже более симпатично.

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

И не забываем, про возможность просмотра отрендеренного результата на GitHub Pages.

Алиса и Боб с примеров диаграмм: откуда они взялись

Если вам приходилось изучать диаграммы последовательности UML или Mermaid, либо в других нотациях, тогда вы точно сталкивались с Алисой и Бобом.

А откуда вообще взялись эти имена? Давайте резберемся.

Впервые эти имена использовались для обозначения принципалов в вышедшей в 1978 году статье «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», над которой работали специалисты в области криптографии Рон Ривест, Ади Шамир и Леонард Адлеман.

Почем именно Алиса (Alice) и Боб (Bob)? Все просто. Для примеров авторам статьи нужны были имена, которые бы начинались на А (англ. A) и Б (англ. B) вместо скучных и банальных «Сторона А» и «Сторона Б», и при этом характеризовались бы лингвистической и мнемонической простотой. Алиса и Боб оказались отличными кандидатами на это. С тех пор эти имена традиционно используются для обозначения принципалов практически во всех материалах, касающихся криптографии.

Получатся, что в диаграммы UML, Mermaid (и иже с ними) они пришли как раз из криптографии. И прижились здесь.

Кстати, помимо Алисы и Боба в криптографии для обозначения принципалов используется немало «эталонных» персонажей (в диаграммы они не «заехали», но знать эти имена для общего развития лишним не будет):

- Carol либо Charlie (C) — третий участник в многопользовательском протоколе.
- Dave (D) — четвертый участник.
- Eve (E) — eavesdropper (подслушивающий). Злоумышленник, который может пассивно перехватывать сообщения между Алисой и Бобом, но не может их изменять.
- Mallory (M) — malicious (злонамеренный). Активный злоумышленник, который может не только перехватывать, но и изменять, удалять или подменять сообщения.
- Trent (T) — trusted third party (доверенная третья сторона). Арбитр или сертифицирующий орган, которому доверяют все стороны (например, Центр сертификации).
- Peggy (P) — prover (доказывающая). Доказывает что-то другой стороне в протоколах с нулевым разглашением.
- Victor (V) — verifier (проверяющий). Проверяет утверждение Пегги.
- Walter (W) — warden (надзиратель). Участник в протоколах стеганографии.