UserNotFoundException:

✅ Глобальный обработчик ошибок в Spring Boot:

Рекомендации:

Салимжанов Р.

Миграции базы данных — важный процесс в разработке, позволяющий управлять изменениями структуры БД. Flyway — популярный инструмент для версионирования и автоматизации миграций.

Он позволяет:

✅ Автоматизировать обновление структуры БД

✅ Контролировать версионность изменений

✅ Обеспечивать безопасность миграций

В этой статье мы разберём:

В pom.xml (Maven):

В application.properties:

Класс FlywayConfig настраивает Flyway для работы с базой данных:

Ключевые параметры:

Класс FlywayRunner выполняет миграции и логирует процесс:

Что делает этот код?

Flyway требует, чтобы миграции лежали в src/main/resources/db/migration/:

При старте Spring Boot:

После запуска в БД появится:

Как видим, до запуска нет таблиц:

После запуска:

✅ 1. Контроль версий

✅ 2. Идемпотентность (безопасность повторного запуска)

✅ 3. Откат изменений (через откатные миграции)

✅ 4. Защита от человеческих ошибок

Ручные sql скрипты могут:

Flyway гарантирует:

✅ 5. Интеграция с CI/CD

Салимжанов Р.

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

Изоляция кода: Бэкенд (логика) и фронтенд (интерфейс) работают независимо.

Масштабируемость: Легко добавлять новые сервисы или обновлять существующие.

Упрощение CI/CD: Каждый компонент можно тестировать и деплоить отдельно.

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

Монорепозиторий — это единое хранилище для всех частей проекта. Вот как может выглядеть структура для двух приложений (app1 и app2):

Преимущества:

1)Все компоненты в одном месте.

2)Общие библиотеки (например, UI-компоненты) можно использовать в нескольких приложениях.

3)Упрощённая настройка зависимостей.

Для примера создадим два приложения (app1 и app2), где бэкенд будет возвращать строку, а фронтенд — отображать её. Код будет одинаковым для обоих приложений — разница только в названиях и строках.

Для app1

Файл: apps/app1/backend/demo/src/main/java/com/example/demo1/HelloController.java

Для app2

Файл: apps/app2/backend/demo/src/main/java/com/example/demo2/HelloController.java

Что здесь происходит?

Каждый бэкенд запускается на своём порту(server.port=8082 - для app1 server.port=8081 - для app2).

По пути /api возвращается уникальная строка для каждого приложения.

А да точно еще следует сделать WebConfig для портов, а то будет возникать ошибка.

Для app1

Файл: apps/app1/frontend/demofront1/src/App.tsx

Для app2

Файл: apps/app2/frontend/demofront/src/App.tsx

Что здесь происходит?

Фронтенд отправляет запрос к /api и отображает ответ бэкенда.

Для каждого приложения создайте файл Dockerfile в папке бэкенда:

Для каждого фронтенда создайте файл nginx.conf:

Чтобы связать все компоненты вашего приложения с помощью Docker Compose, вам нужно создать файл docker-compose.yml. Этот файл обычно размещается в mono-repo/.

Файл: docker-compose.yml

Каждое приложение работает в своей «паре» (бэкенд + фронтенд).

Сервисы общаются через общую сеть app-network.

Фронтенд app1 доступен на http://localhost:3002 , app2 — на http://localhost:3000.

Перейдите в корневую папку (mono-repo).

Выполните:

docker-compose up --build

Проверьте:

app1: http://localhost:3002 → Должно отобразиться:

app2: http://localhost:3000 → Должно отобразиться:

Изоляция контейнеров Каждый сервис работает в своей «песочнице». Даже если злоумышленник взломает фронтенд, он не сможет напрямую получить доступ к данным бэкенда.

Минимальные права Nginx во фронтенде имеет доступ только к статическим файлам, а бэкенд не имеет доступа к файловой системе фронтенда.

Сетевые ограничения Сервисы общаются через внутреннюю сеть Docker, которая недоступна из внешнего мира. Порт бэкенда (8081/8082) открыт только для фронтенда.

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

Используя монорепозиторий и Docker, вы:

Упрощаете разработку — все компоненты под рукой.

Ускоряете деплой — одна команда запускает весь проект.

Повышаете безопасность — изоляция и минимальные права сводят риски к минимуму.

Это как конструктор: каждый модуль на своём месте, а Docker — инструкция по сборке. Начните с малого, и вы быстро освоите этот подход!

Салимжанов Р.Д.

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

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

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

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

npm install @mantine/core @mantine/hooks

или

yarn add @mantine/core @mantine/hooks

После установки библиотеки, мы можем обернуть наше приложение в MantineProvider, который предоставляет доступ ко всем компонентам и темам Mantine. В нашем примере это уже сделано в файле App.tsx:

MantineProvider является корневым компонентом, который обеспечивает доступ к темам и стилям Mantine во всем приложении.

Для того чтобы стили компонентов Mantine корректно применялись, необходимо импортировать глобальные стили библиотеки. Это делается с помощью строки:

import '@mantine/core/styles.css';

Этот импорт подключает базовые стили, которые необходимы для корректного отображения компонентов Mantine. Без этого шага компоненты могут выглядеть неправильно или не соответствовать ожидаемому дизайну. В нашем примере это уже сделано в файле App.tsx.

(не знаю почему именно кнопки, просто для примера я так захотел)

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

Для работы с кнопками необходимо импортировать компонент Button из @mantine/core:

import { Button } from '@mantine/core';

Давайте рассмотрим несколько вариантов использования кнопок в Mantine:

Это самая простая кнопка, которая отображает текст \"Нажми меня\". По умолчанию кнопка имеет стиль, соответствующий текущей теме Mantine.

Здесь мы используем проп size, чтобы изменить размер кнопки. Mantine поддерживает несколько размеров: xs, sm, md, lg, xl.

В этом примере мы добавляем иконку слева от текста кнопки. Для этого используется проп leftSection. Иконка импортируется из библиотеки @tabler/icons-react, которая часто используется вместе с Mantine.

Здесь мы используем проп variant со значением gradient, чтобы создать кнопку с градиентным фоном. Проп gradient позволяет настроить цвета и угол градиента.

Вернемся к нашему компоненту Home, где мы используем кнопки:

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

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

Использование Mantine в сочетании с TypeScript позволяет создавать современные, типобезопасные и легко поддерживаемые React-приложения. Библиотека предоставляет мощные инструменты для создания пользовательских интерфейсов, которые выглядят привлекательно и работают эффективно. В этой статье мы рассмотрели основы работы с Mantine, включая обертывание приложения в MantineProvider, создание простых кнопок и использование глобальных стилей. Вы же можете экспериментировать!!!

Салимжанов Р.Д.

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

AES (Advanced Encryption Standard) — это симметричный алгоритм шифрования, который использует один и тот же ключ для шифрования и дешифрования данных. Он работает с блоками фиксированного размера (128 бит) и поддерживает ключи длиной 128, 192 или 256 бит.

CBC (Cipher Block Chaining) — это режим работы AES, который добавляет дополнительную защиту. Каждый блок данных перед шифрованием \"смешивается\" с результатом шифрования предыдущего блока. Это делает шифр более устойчивым к атакам.

Зачем шифровать токены?

Рассмотрим, как интегрировать шифрование токенов с использованием AES в режиме CBC в ваше Spring Boot приложение.

Этот класс — наш цифровой сейф:

Сначала создадим класс AesEncryptionUtil, который будет содержать методы для шифрования и дешифрования данных с использованием AES/CBC/PKCS5Padding.

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

Класс AesEncryptionUtil — это твой робот-шифровальщик, который умеет делать две вещи:

Запираем письмо в сейф (шифрование)

Шаг 1: Проверяем ключ

Робот говорит: «Дайте мне секретный ключ длиной минимум 16 символов!»

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

Про файл .env я рассказывал в одной из своих статей

Салимжанов Р.Д.

Шаг 2: Генерируем «соль» (IV)

Робот берет 16 случайных кубиков (IV — Initialization Vector).

Это как посыпать письмо солью перед тем, как его запечатать — так сейф будет уникальным.

Шаг 3: Создаем замок (ключ)

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

Шаг 4: Шифруем

Письмо (токен) нарезается на кусочки, смешивается с «солью» и запирается в сейф.

Робот использует алгоритм AES-CBC — это как сложный пазл, где каждый кусочек зависит от предыдущего.

Шаг 5: Упаковываем

Сейф (IV + зашифрованные данные) кодируется в Base64 — это как перевод текста на язык роботов, чтобы его можно было безопасно передать.

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

Представьте, что у вас есть здание с разными зонами доступа:

Это и делает SecurityFilterChain — управляет доступом пользователей к ресурсам, проверяя их права.

Шаг 1: Получаем токен

После успешного входа Spring передает нам токен аутентификации:

String token = authentication.getCredentials().toString();

Шаг 2: Получаем секретный ключ

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

String secretKey = System.getenv(\"AES_SECRET_KEY\");

if (secretKey == null) {

System.out.println(\"AES_SECRET_KEY is not set in environment variables!\");

}

Шаг 3: Шифруем токен

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

String encryptedToken = AesEncryptionUtil.encrypt(token, secretKey);

System.out.println(\"Encrypted token: \" + encryptedToken);

Шаг 4: Сохраняем в cookie

Мы создаем cookie с зашифрованным токеном, которая:

1)HttpOnly—браузер не может прочитать её через JavaScript (защита от XSS).

2)Secure—отправляется только через HTTPS.

3)MaxAge—живёт 7 дней.

Cookie cookie = new Cookie(\"encrypted_token\", encryptedToken);

cookie.setHttpOnly(true);

cookie.setSecure(true); // Только HTTPS

cookie.setPath(\"/\");

cookie.setMaxAge(7 * 24 * 60 * 60); // 7 дней

response.addCookie(cookie);

System.out.println(\"Encrypted token set in cookie.\");

После этого происходит редирект на главную страницу:

response.sendRedirect(\"/\");

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

Давайте разберем каждую строку:

Token received:

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

AES_SECRET_KEY found: 1234567890abcdef

Здесь сообщается, что был найден секретный ключ для шифрования AES. В данном случае ключ имеет значение 1234567890abcdef. Обратите внимание, что использование простых и предсказуемых ключей (как в этом примере) не является безопасной практикой.

Encrypting data with AES key: 1234567890abcdef

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

Encryption successful. Encrypted data size: 32

Сообщение подтверждает, что шифрование прошло успешно, и указывает размер зашифрованных данных (в байтах). В данном случае размер составляет 32 байта.

Encrypted token: 4bJ7ok9Vo+/NUwPoxqfBLlev33ne3Gxulfib9szmL4M=

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

Encrypted token set in cookie.

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

Почему стоит потерпеть сложности?

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

1) Java AES Encryption and Decryption// [электронный ресурс]. URL: https://www.baeldung.com/java-aes-encryption-decryption (дата обращения 08.02.2025).

2) AES шифрование и Android клиент // [электронный ресурс]. URL: https://habr.com/ru/companies/rambler_and_co/articles/279835/ (дата обращения 09.02.2025).

3) аутентификация при помощи Spring Boot // [электронный ресурс]. URL: https://habr.com/ru/articles/784508/ (дата обращения 08.02.2025).

Салимжанов Р.Д.

В современном приложении крайне важно организовать безопасный доступ пользователей к различным ресурсам в зависимости от их роли. В этой статье мы рассмотрим, как реализовать ролевую модель доступа, используя Spring Boot, PostgreSQL и Keycloak в качестве сервера авторизации.

В предыдущей статье я уже разбирал, как настроить Keycloak и Spring Security на Java. На основе того приложения мы добавим ролевую модель, так чтобы роли пользователей извлекались динамически из базы данных PostgreSQL, а не хранились статически в токенах. Такой подход обеспечит большую гибкость и безопасность, позволяя изменять роли пользователей без необходимости пересоздания токенов.

Предыдущая статья:

Салимжанов Р.Д.

Итак, я не вносил изменений в файл docker-compose.yml, который мы будем использовать для запуска Keycloak. Как и в прошлый раз, запускаем контейнер с помощью команды docker-compose up . После успешного запуска контейнера вы сможете получить доступ к Keycloak по адресу http://localhost:8080. Далее мы можем продолжить настройку Keycloak в соответствии с требованиями.

Если вдруг он уже настроен, вы можете работать в нем, или удалить контейнеры, сети, образы и данные, чтобы очистить окружение. Выбор за вами. Я почистил и настроил заново:

Realm name: app_realm

Client ID: spring-app

Users: test_user

Email: test@example.com

Password: test123

Подробную настройку можно почитать в моей предыдущей статье.

Более подробно мы рассмотрим, как настроить мапперы токена в Keycloak для добавления свойства preferred_username в токен доступа. Это необходимо для того, чтобы приложение могло получать и использовать имя пользователя в удобном формате, что упрощает управление доступом и персонализацию пользовательского опыта.

1)В клиенте spring-app перейдите на вкладку \"Client Scopes\": Это позволит вам управлять областями доступа, которые определяют, какие данные будут включены в токены для вашего клиента.

2)Выберите \"spring-app-dedicated\" вашего клиента: Выбор конкретной области доступа гарантирует, что изменения будут применены только к нужному клиенту.

3)Нажмите \"Add mapper(By configuration)\": Это действие позволит вам создать новый маппер, который будет добавлять необходимые данные в токен.

4)Выберите \"User Property\": Этот тип маппера позволяет извлекать свойства пользователя из базы данных Keycloak.

5) Заполните поля и сохраните:

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

Щя покажу, как это работает:

Для начала сгенерируем токен.

curl -X POST http://localhost:8080/realms/app_realm/protocol/openid-connect/token -H \"Content-Type: application/x-www-form-urlencoded\" -d \"client_id=spring-app\" -d \"client_secret=ВАШ_КЛИЕНТСКИЙ_СЕКРЕТ\" -d \"username=test_user\" -d \"password=test123\" -d \"grant_type=password\"

Скопируйте access_token из ответа.

Вставьте на https://jwt.io

Если все правильно, то вы должны увидеть \"preferred_username\": \"test_user\".

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

roles — хранит роли (USER, ADMIN, MODERATOR).

users — хранит информацию о пользователях (username, email).

user_roles — связывает пользователей и их роли.

SQL-запросы для создания базы данных

В файле application.properties укажем параметры подключения к базе данных и Keycloak:

Обновление зависимостей в pom.xml:

Сущность RoleEntity