Как реализовать Refresh Tokens в ASP.NET Core и как отозвать токены пользователя 👇

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

Обычно JWT-аутентификация использует два токена:

● Access token — даёт доступ к защищённым ресурсам и живёт недолго (обычно 5–10 минут).
● Короткий срок жизни снижает риски при компрометации.

Refresh token — нужен для получения нового access token без повторного входа пользователя в систему.

Если access token живёт всего несколько минут — пользователь будет постоянно переавторизовываться. Это ужасный UX.

Здесь и вступает в игру refresh token. Он позволяет «тихо» получить новый access token, когда текущий истёк, не требуя логина.

Refresh token, как правило, живёт дольше — от нескольких дней до недель.

Anton Martyniuk рассказал:

🔸Что такое refresh токены и как они работают
🔸Как реализовать их в ASP.NET Core
🔸Как обеспечить безопасность и соблюдать best practices
🔸Как отзывать refresh токены, чтобы динамически обновлять права доступа пользователя

Хочешь прокачать безопасность в ASP.NET Core по индустриальным стандартам? вот статья

👉 @KodBlog

GitHub Copilot Chat теперь с открытым кодом

Microsoft сделали первый шаг к превращению VS Code в полноценный опенсорс AI-редактор

Теперь можно заглянуть под капот: как работает agent mode, что уходит в LLM, как устроены промпты и даже какую телеметрию они собирают

Код доступен на GitHub ✌️

👉 @KodBlog

C#‑«скрипт» для отправки HTTP-запроса с использованием Flurl.

Эта возможность появится в .NET 10 — подробнее

👉 @KodBlog

Как быстро расчистить раздутые API-контроллеры:

Используй метод-инъекцию 😨

Это малоизвестная фича в ASP.NET Core, которая позволяет внедрять зависимости не в конструктор, а напрямую в метод-обработчик.

Для этого используется [FromServices] IYourService

Хотя [FromServices] можно и опустить — оно не обязательно.

Когда стоит использовать метод-инъекцию:

🔸когда сервис используется только в одном экшене
🔸когда конструктор начинает превращаться в кашу из зависимостей
🔸когда сервис тяжёлый, и важно контролировать его создание и утилизацию

Да, внедрение через конструктор — это дефолтный подход.
Но метод-инъекция — это удобный инструмент, если ты:

- хочешь придерживаться Single Responsibility Principle

- не хочешь превращать контроллер в свалку зависимостей

👉 @KodBlog

C# наконец-то получает дискриминируемые объединения

Ну, возможно?

Появилось новое предложение по добавлению объединений типов (Type Unions) в C#. И это действительно важно.

Почему?

Это открывает нативную поддержку таких конструкций, как Result и Option.

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

Я уже много лет выступаю за использование паттерна Result. Но до сих пор отсутствие поддержки на уровне языка делало его применение неуклюжим.

Теперь это может измениться.

В предложении описываются нативные union-типы, включая поддержку pattern matching, проверку исчерпывающего перебора (exhaustiveness checks) и другие фичи.

Не хочешь ждать?

Вот как можно реализовать паттерн Result уже сегодня

Если предпочитаешь бросать исключения — можешь это пропустить. 🤵

👉 @KodBlog

Миф о том, что Dapper на 50% быстрее EF Core — это неправда

Ты наверняка слышал, как говорят, что Dapper на 30%, 50% или даже в 2 раза быстрее, чем EF Core?

Это утверждение гуляет повсюду.

Но проведя реальный бенчмарк на .NET 8, с таким запросом:

"Получить топ-5 пользователей, которые оставили больше всего комментариев за последние 7 дней к постам в категории '.NET'"

Результаты удивили:

🔸Dapper: 2.07 мс
🔸EF Core: 2.43 мс
(см. скриншот для деталей)

Разница — всего 0.36 мс, или 14%.

Да, Dapper выделяет меньше памяти, но для большинства приложений эта разница мизерная.

Что это значит?

↳ Для 80% проектов такая разница в производительности вообще не критична.
> Поэтому EF Core — мой выбор по умолчанию.

12 причин выбрать EF Core вместо Dapper в реальной разработке:

1. Автоматическое отслеживание изменений сущностей — меньше ручного кода для insert, update, delete.

2. LINQ-запросы с проверкой на этапе компиляции, которые трансформируются в SQL.

3. Code-First миграции упрощают эволюцию схемы базы данных.

4. Возможность реверс-инжиниринга существующей базы в модели.

5. Навигационные свойства позволяют работать с отношениями без ручных join-ов.

6. Поддержка eager, lazy и explicit загрузки данных.

7. Глобальные фильтры запросов для soft delete и мультиарендности.

8. Value Conversions — удобное отображение кастомных типов на столбцы в БД.

9. Встроенные политики повторных попыток (retry) делают соединения с БД более устойчивыми.

10. Interceptors — можно реализовать аудит, логирование, кастомные поведения.

11. Один и тот же запрос работает с множеством провайдеров: SQL Server, PostgreSQL, MySQL, Oracle, SQLite и др.

12. Поддержка миграций сразу для нескольких БД из одного кода.

Важно:

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

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

👉 @KodBlog

Как реализовать ограничение частоты запросов для аутентифицированных пользователей?

Можно использовать ID пользователя в качестве ключа разбиения (partition key) для лимитирования.

В .NET есть механизм partitioned rate limiter, который позволяет это настроить.

ID пользователя можно получить из claim'а в JWT или из cookie.

Такую политику лимитирования можно применить:

🔸На уровне API — для простых сценариев
🔸На уровне reverse proxy — при масштабировании

Хочешь узнать о более продвинутых сценариях лимитирования?

Начни отсюда: тык

👉 @KodBlog

Какой синтаксис мокинг-библиотеки для dotnet вам больше по душе из примеров выше?

Moq?
NSubstitute?
FakeItEasy?

и какой библиотекой вы пользуетесь сами и почему? 🤵

👉 @KodBlog

Вот 12 популярных инструментов для создания архитектурных диаграмм:

1. C4 Model
↳ Удобная для разработчиков модель визуализации архитектуры на 4 уровнях: Контекст, Контейнер, Компонент, Код.
🔸icepanel.io или structurizr.com

2. draw.io
↳ Бесплатный open-source веб-инструмент для создания диаграмм. Интегрируется с облачными хранилищами.
🔸drawio.com

3. PlantUML
↳ Текстовый движок для генерации UML и других диаграмм из кода. Идеален для git‑флоу.
🔸plantuml.com

4. Mermaid
↳ Markdown-подобный синтаксис для рендеринга блок-схем, последовательностей и т.д.
🔸mermaid.js.org

5. Excalidraw
↳ Open-source инструмент для совместного рисования в стиле "от руки".
🔸excalidraw.com

6. mingrammer/diagrams
↳ Библиотека на Python: "диаграммы как код". Позволяет описывать cloud-инфраструктуру кодом.
🔸GitHub

7. Archimate
↳ Стандартизированный язык моделирования enterprise-архитектуры.
🔸archimatetool.com

8. Miro
↳ Онлайн-доска для совместной работы: брейншторминг, диаграммы и не только.
🔸miro.com

9. Lucidchart
↳ Облачный инструмент с умными функциями: AI-диаграммы, схемы архитектуры и т.д.
🔸lucidchart.com

10. CloudSkew
↳ Онлайн-редактор с иконками AWS/Azure/GCP/K8s. Идеален для визуализации облачной архитектуры.
🔸cloudskew.com

11. D2
↳ Декларативный язык диаграмм, превращающий текст в структурированные визуализации, подходящие для версионирования.
🔸d2lang.com

12. Cloudcraft
↳ Заточен под диаграммы архитектуры AWS и Azure.
🔸cloudcraft.co

Что бы ты ещё добавил? 🧠

👉 @KodBlog

Большинство разработчиков неправильно понимают DDD.

Они изучают паттерны (Aggregates, Repositories, Value Objects) и применяют их вслепую.

Но суть DDD — не в паттернах, а в глубоком понимании домена.

Я сам совершал эту ошибку на старте. Помогли не паттерны, а выравнивание с бизнесом.

Главная сложность — коммуникация.

Разные команды называли одно и то же по-разному. Всё изменилось, когда мы построили общий язык.

Истинная ценность DDD:

🔸Общее понимание
🔸Чёткая терминология
🔸Точные модели

После 6+ лет работы вот мой совет:

🔸Разговаривай с бизнесом

🔸Учись говорить на их языке

🔸Моделируй то, что действительно важно

Паттерны тебя не спасут. Поможет только понимание.

И нет, DDD — это не архитектура.

А вот архитектура: клик

А как ты подходишь к DDD? 🫥

👉 @KodBlog

Работать с HTTP-заголовками это сложно?

Короткий ответ: нет. И вот почему

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

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

Заголовки делятся на 4 группы по контексту:

🔸Request headers (заголовки запроса)
🔸Response headers (заголовки ответа)
🔸Representation headers (информация о формате представления)
🔸Payload headers (сведения о теле запроса/ответа)

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

Добавить заголовки в HTTP-запрос можно двумя способами:

🔸Добавить ко всем запросам
🔸Добавить только к конкретному запросу

Если нужно извлечь значение из заголовка , это тоже делается просто.

Оба сценария реализуются достаточно прямолинейно.

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

🔸Использовать лаконичные и понятные заголовки
🔸Настраивать кэширование через заголовки (Cache-Control, ETag)
🔸Учитывать CORS (Access-Control-Allow-Origin)
🔸Обеспечивать безопасность уже на уровне заголовков (Strict-Transport-Security, Content-Security-Policy и др.)

👉 @KodBlog

Не засоряй код лишним

До сих пор иногда вижу, как разработчики так делают.

Удели пару секунд первому фрагменту кода — он отлично иллюстрирует распространённый зашумлённый антипаттерн.

Видишь проблему? Каждое свойство избыточно повторяет имя класса.

А теперь посмотри на второй фрагмент — определение и использование стали гораздо чище и понятнее, верно?

Запомни: хороший код задаёт контекст один раз, на нужном уровне абстракции.

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

👉 @KodBlog

EF Core медленный.
ТАКЖЕ ОНИ -> Используют EF Core, чтобы вернуть:

> 25 полей из таблицы,
> 1 000 000 строк за раз,
> включая данные из всех связанных таблиц.

Лучшая оптимизация производительности — это научиться правильно пользоваться инструментами

👉 @KodBlog

Как создать собственную социальную сеть на .NET

Это отличный проект для самостоятельной реализации. 🤓

Базовая реализация платформы может включать следующие сущности:

↳ Пользователи

↳ Посты и категории

↳ Лайки и комментарии

↳ Лента

↳ Уведомления

Рассмотрим реальный кейс:

Пользователь открывает сайт соцсети и видит:

↳ Ленту с актуальными постами

↳ Свои собственные публикации

↳ Уведомления о новых постах, комментариях и лайках к интересующим его записям

Типичное frontend-приложение делает три отдельных запроса к серверу:

Получение ленты

GET /api/feed?userId=1&count=10

Получение уведомлений

GET /api/notifications?userId=1&count=10

Получение постов пользователя

GET /api/users/1/posts?count=10

У этой реализации два ключевых недостатка:

❌Клиенту приходится делать три отдельных запроса к серверу

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

Решение — GraphQL

GraphQL был создан как альтернатива REST, чтобы решить эти проблемы.

Hot Chocolate это самый эффективный и функциональный open-source GraphQL-сервер в экосистеме .NET. Он позволяет легко строить масштабируемые GraphQL API и шлюзы.

Преимущества Hot Chocolate по сравнению с REST API:

✅Клиент сам выбирает, какие поля ему нужны — никакого overfetch/underfetch
✅Все данные можно запросить одним запросом, без лишних round-trip’ов
✅Автогенерация документации, генерация кода и автодополнение в IDE синхронизируют frontend и backend
✅Встроенные фильтрация, сортировка и пагинация — middleware всё берёт на себя, причём делает это лучше и проще, чем OData
✅Интерфейс Nitro GraphQL позволяет визуально исследовать типы, собирать запросы и тестировать их за секунды

Я использую Hot Chocolate GraphQL в продакшене уже более трёх лет, и это сильно прокачало мои подходы к построению API.

Автор собрал простую реализацию социальной сети на базе Hot Chocolate GraphQL, и сегодня поделился пошаговой инструкцией с разработчиками, как сделать это правильно с учётом best practices.

Исходный код доступен бесплатно.

👉 @KodBlog

Как обезопасить свой API?

Вот 5 рекомендаций, которые помогут:

→ Используйте надёжную аутентификацию и авторизацию
→ Валидируйте входные данные и экранируйте выходные
→ Настройте ограничение частоты запросов
→ Шифруйте весь трафик
→ Обеспечьте наблюдаемость

👉 @KodBlog

Жизнь коротка, используй библиотеки .NET

Вот список популярных библиотек, которые стоит рассмотреть:

1. ORM
- EF Core
- Dapper ORM

2. Инструменты для API
- SignalR
- FluentValidation
- MediatR
- YARP

3. Тестирование
- xUnit
- Testcontainers
- FluentAssertions
- Moq
- Verify

4. Логирование и мониторинг
- Serilog
- NLog
- OpenTelemetry

5. Внедрение зависимостей (DI)
- Autofac
- Scrutor

6. Фоновая обработка
- Hangfire
- Quartz .NET

7. Работа с HTTP
- Polly
- RestSharp
- Refit

8. Работа с Office-документами
- ClosedXML
- EPPlus
- Excel-DNA

9. Аутентификация и авторизация
- Microsoft.AspNetCore.Identity
- openiddict
- Keycloak

10. Очереди и брокеры сообщений
- RabbitMQ
- MassTransit
- NServiceBus

P.S. А ты бы какую библиотеку добавил? 🥰

👉 @KodBlog

Изменение стандартного представления класса в режиме отладки

К сведению: мы можем изменить стандартное отображение класса в отладчике C# с помощью атрибута DebuggerDisplay

👉 @KodBlog