Анализ системы защиты сайта от ботов на примере letu.ru с использованием javascript reverse engineering.

Гипотетическая ситуация — ваш работодатель поручил вам выбрать Identity and Access Management platform.

Обязательно: open‑source (Apache 2.0), self‑hosted, OAuth 2.0, OIDC, SAML, LDAP.

Для тех кому интересно узнать, что есть еще кроме Keycloak.

Привет, Хабр!

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

Identity and Access Management (IAM) выступает как наша первая линия обороны. Оно не просто защищает наши данные, но и гарантирует, что правильные люди имеют доступ к нужной информации в нужное время. Каждая вторая транзакция в мире происходит онлайн, безопасность становится не просто приоритетом, а необходимостью.

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

Цикл постов про Keycloak. Часть вторая: Контроль доступа на уровне приложения.

Этот пост является продолжением данной статьи. 

В прошлый раз мы настроили ABAC (Attribute Based Access Control) с использованием Keycloak, теперь реализуем проверку разрешений на уровне приложения.

Считать, что управление — это легко, может только человек, который ни разу в жизни не руководил. Ведь это просто только со стороны. Достаточно попробовать, чтобы сразу столкнуться с проблемами и трудными решениями. И за вас с этим никто не разберется. Кроме людей, которые уже с такими проблемами столкнулись. Ведь зачем изобретать велосипед, который уже сделали? 

Люди бережно собирают свои знания и лучшие практики и делятся ими с миром. Одним из важных источников информации для руководителя можно считать PMBoK, или Project Management Body of Knowledge. Это свод знаний по управлению проектами, где описаны процессы, их цели и способы их внедрения. Можно сказать, что этот сборник — это настольная книга руководителя или библия тимлида. Называйте как больше нравится, сути дела это не меняет.  

В программировании нет вообще никаких непреложных истин. Даже самые очевидные правила могут иметь контекст, в которых их применять нельзя. К сожалению в 99% организаций есть прям заповеди, обязательные к исполнению. И есть правила, которые считаются правилами хорошего тона (как не сморкаться в занавеску). Однако всегда бывают ситуации, когда лучше все-таки сморкаться.

Вот примеры.

1) Например, DRY — don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.

«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец

Т.е. DRY — хороший принцип, но бывают исключения.

Если вы чувствуете профессиональное выгорание, то возможно лучший ответ на это... пойти в паломничество! Рассказываю о мало известном маршруте Камино-де-Сантьяго через Португалию, о том сколько стоит такой поход и о том почему паломничество это вообще один из лучших способов путешествовать. Хотя, по правде говоря, паломничество - это больше чем просто путешествие…

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

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

Некоторое время назад Озон громко заявил о создании платформы для удалённого заработка, под названием "Озон-Профит". Заявлялось, что данная платформа позволит, имея компьютер и доступ в интернет, зарабатывать до 20 тысяч в месяц, работая по четыре часа в день, не выходя из дома. Мой сын не так давно экспериментировал с "Яндекс-толокой", поэтому я примерно понимал, о каких масштабах "заработка" может реально идти речь. Тем не менее - у меня есть пожилые родственники, которым не хватает пенсии, и у которых много свободного времени, и я подумал, что им это будет интересно.

Первый звоночек прозвенел, когда первый же из тех, кому я предложил посмотреть «Озон.Профит», категорически отказался от этой затеи сразу после попытки пройти обучалку. Отказ сопровождался словами "что-то как-то совсем бредово, можно только в глубокий минус уйти". Если что - человек на тот момент на полном серьёзе рассматривал варианты фулл-тайм работы за 1 МРОТ. Дальше я решил почитать отзывы в интернете, и обнаружил, что реально народ там зарабатывает по пять тысяч рублей в месяц максимум, а самой распространённой суммой месячного заработка было "2-3 тысячи в месяц"... Мне стало прямо совсем интересно, поэтому было принято решение выделить пару-тройку вечеров на то, чтобы составить своё собственное мнение.

Знаете, что меня всегда удивляло? Если вернуться на 1000 лет в прошлое, то мы увидим воина, радикально отличающегося обликом от современного солдата (здесь и далее речь про Европу). Однако стоит нам от отметки XI века снова отступить на те же 1000 лет в прошлое, как мы увидим примерно такого же воина, который не так уж чтобы отличался обликом от своего средневекового собрата. Та же кольчуга или даже пластинчатый доспех, тот же меч и щит. Конечно, различия есть, но в большей степени отражают специфику военных действий, нежели разницу в технологиях, которые, вроде как, должны были куда-то двигаться за прошедшее тысячелетие.

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

Привет, друзья!

В этой серии из 3 статей я расскажу вам о Nest (NestJS) — фреймворке для разработки эффективных и масштабируемых серверных приложений на Node.js. Данный фреймворк использует прогрессивный (что означает текущую версию ECMAScript) JavaScript с полной поддержкой TypeScript (использование TypeScript является опциональным) и сочетает в себе элементы объектно-ориентированного, функционального и реактивного функционального программирования.

Под капотом Nest использует Express (по умолчанию), но также позволяет использовать Fastify.

• Шпаргалка по Express API
• Карманная книга по TypeScript
• Шпаргалка по TypeScript

В первой статье рассматриваются основы работы с Nest, во второй — некоторые продвинутые возможности, предоставляемые этим фреймворком, в третьей — приводится пример разработки простого React/Nest/TypeScript-приложения.

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

Это первая часть руководства.

1. Богатая (насыщенная) модель — данные и поведение инкапсулируются внутри объектов предметной области.
2. Анемичная модель — в объектах предметной области инкапсулируются только данные, поведение (методы) выносится в отдельный слой сервисов.

Всем привет! Меня зовут Роман Халкечев, я руковожу отделом аналитики в Яндекс.Еде. Одно из ключевых направлений этого сервиса — логистика. Эффективность алгоритмов логистики во многом и определяет само существование сервисов доставки. Сегодня я расскажу читателям Хабра о нашем новом алгоритме, который помог курьерам сократить время простоя. Вы узнаете, из чего складывается время ожидания доставки заказа и зачем мы считали скорость приготовления килограмма условной еды. Но обо всём по порядку.

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

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

Нет! Если у вас есть висячие указатели, то память никогда не освободится и вам в любом случае придется исправлять это, выполняя ручное управление памятью. Сборщики мусора волшебным образом не исправляют все ошибки.