🌶 IT-Конференция 🌶

Мои друзья устраивают мощную IT-конференцию, всем дико советую съездить

Душнилы на страже корректности вакансий

Node.js / TypeScript file and folder name convention Часто замечаю проблему с тем, как люди именуют файлы и папки в Node.js приложениях

Тизерну правильный способ: lower kebab-case

А вот почему, можете почитать в статье:

https://medium.com/@it-kachalka-david-shekunts/node-js-typescript-file-and-folder-name-convention-8a2f5cb0a632

Настройка Fish Shell + NVM + Macbook M1 (Apple Chip) Только что у себя все настроил и записал простой набор действий (вдруг кто использует fish и хочет воспользоваться nvm)

Что это такое:

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

https://medium.com/@it-kachalka-david-shekunts/%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-fish-shell-nvm-macbook-m1-apple-chip-5c59fb0925e4

🔐 Шифрование запросов с помощью HMAC и AES-256-CBC

По посту, который писал выше, выпустил статью на Medium, куда приложил примеры кода на JS

Пиздите используйте на здоровье:

ссылка на medium

___

🤢 Перестаньте использовать express / koa и начните использовать ...

При построении абсолютного любого API мне нужны:

1. Схема API с возможностью интроспекции (трансформации схемы в типизацию языка)
2. UI с демонстрацией API (например, swagger)
3. Типизация функционала библиотеки (чтобы все request и response правильно типизировались по схеме)
4. Миддлвары, logger, контекст для DI, плагины, etc.

Express и koa  -  библиотеки с минимальным набором функционала и добавить туда вышеописанные пункты можно при помощи сторонних библиотек. C 4-м пунктом сторонние библиотеки более менее справляются, а вот с первыми тремя постоянно возникают какие-то проблемы.

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

Но есть библиотека, которая решает все эти вопросы разом - Fastify

Решил собрать трюки по вышеописанным пунктам в данной статье

Мощной, вам, прокачки 💪

😭 Knex JS ломает logger

Knex – одна из самых известных библиотек для работы со SQL в NodeJS. И как полагается, подобного рода библиотеки могут принимать на вход внешний логгер.

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

Догадались в чем может быть проблема? Ответ через 3... 2... 1...

А проблема в том, что если ваш логгер под собой использует "this" без байндинга к инстансу (что не является обязательным), то теперь его "this" будет ссылаться на класс внутреннего логгера Knex...

В последних проектах я часто использую логгер Pino и внутри его логики используется "this" без байдинга и это приводит к крашу приложения

Чтобы все заработало приходится использовать мерзкий хак (фото 2)

Чему это нас учит?

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

Мощной вам прокачки 💪

🔐 Шифрование запросов

Мы нашли решение, хочу с вами поделиться:

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

Один из самых простых вариантов – использование HMAC (его используют Ю.Касса, Тинькоф, Страйп, etc.)

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

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

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

Хранить его удобно в БД, но что если БД уведут?

Решение оказалось банально простым: вместо того, чтобы хранить HMAC-секрет в открытом виде, мы будем его шифровать, когда кладем в БД, и дешифровать, когда создаем подпись для сверки.

Для этого идеально подходит алгоритм "aes-256-cbc". Секреты для него хранятся в env приложения.

Получается, даже если уведут БД, у злоумышленников не будет возможности расшифровать hmac-секреты, а чтобы это сделать, нужно иметь или доступ к приложению, или дамп памяти приложения.

Короче, шифрование шифрование шифрованием погоняет, такие дела

P.S.

У меня корона уже 4-ю неделю, поэтому я малоактивный 🙁 Будьте аккуратнее, правда, крайне много заражений последнее время, и даже при хорошем здоровье ощущения, как болеть 3-ный бронхитом

💬 Друзья, у меня к вам есть вопрос: кто-нибудь решал проблему подписей запросов симметричным / асимметричным шифрование?

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

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

Есть идеи?

Видео по курсу 🔥 Advanced Node.js & TypeScript

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

https://www.youtube.com/watch?v=MUosEJXDvnk

Пока занято 3 места и 5 забронированно из 12 доступных мест, так что если интересно, пишите, забронирую для вас место

P.S.

У меня было всего 3 дня на запись и монтаж, поэтому сорян там нет особо картинок / графики / эффектов / работы с камерой и подобного, только мой чистый пиздеж поток мыслей