Блокировка GitHub?

🤔 Хочется подумать чем им навредил гитхаб.
👨‍💻 Но хотя там имеется большое количество обходов блокировок, на что можно подумать первым делом.

🖕 С одной стороны хочется сказать какого * ** **

😑 С другой ничего хорошего и не сказать.

🤯 И их тейк, что неудачные соединения достигнут 100% из-за чего?
💨 Это из-за того что сервера резко в пыль превратятся как с гугловскими было.

💩 А их аналоги GitVerse и GigaChat, нет уж, спасибо.

💬 SocketChat

👀 Где-то месяц назад писал (а может и два, хех), что разбирался с WebSockets как раз тогда собрал рабочий сервер. Решил наконец выложить то, что тогда получилось написать.

⚙️ Что внутри:
👨‍💻 Сервер, который транспортирует сообщения и регает юзеров
💻 Клиент с двумя режимами
💬 One2One чат или группа
🔐 Регистрация через POST запрос + logout

0️⃣1️⃣ Всё работает на самописном бинарном протоколе, под протоколом имею в виду просто договорённость о том, как выглядит пакет, который гоняется по системе.

💀 Безопасности ноль (максимум XOR, чтобы не слать совсем в открытом виде) проект писал чисто чтобы пощупать WebSockets, не более.
🔗 https://github.com/W1xon/SocketChat

👋 Всем привет! Слишком давно не было от меня новостей, пришло время прервать тишину.
📚 Сначала была сессия, которую я успешно сдал, а сразу после неё я решил попробовать свои силы и подался на стажировку .NET-разработчика.
🎯 На данный момент прошёл уже два этапа: контест и экзамен по основам C#. По обоим набрал 80%+ правильных ответов, так что теперь жду обратную связь.
💻 Естественно, сидеть сложа руки во время ожидания я не стал и решил освежить в памяти ASP.NET.
👨‍💻 В процессе превратил один из своих старых проектов в веб-сервис, обязательно покажу его чуть позже.
🧠 Также решаю задачки на LeetCode.
☀️ Вот такие новости на данный момент. А как у вас проходит лето?

P.s. Пока нахожусь в деревне, вспомнил как кататься на велосипеде, отсюда и картинка к посту

👨‍💻 А вот собственно и сам веб-сервис: прокинул туннель через Cloudflare, есть вероятность, что файлы будут грузиться долго.

🎨 Это воплощение моего конвертера в вебе, есть ограничения, т.к. он хостится локально у меня.

🤏 Чуть больше тех. аспектов в следующем посте, а пока можете потестировать. Либо заддосить

P.s. статус активности: сервер выключен 🛑.

🔐 Refresh Token Rotation

👨‍💻 Расскажу вам немного про механизм ротации токенов. В моём проекте NetWalker есть пользователи и вся сопутствующая логика авторизации.

❓ Но как серверу понять, что юзер это действительно конкретный юзер?

🎫 Тут нам помогает JWT токен (access_token), который сервер генерирует на небольшое время. Как только время жизни истекает, токен становится невалидным и юзера по идее должно выкинуть из системы.

🤦‍♂️ Но мы же не хотим видеть, как каждые 10-15 минут приложение просит логиниться заново.

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

💡 Решение проблемы: связка с refresh токеном и его обязательная ротация.

⚙️ Как устроен этот механизм:
🔹 Помимо короткоживущего access_token, сервер генерирует долгоживущий refresh_token (например, на 30 дней) и сохраняет его в базу данных.
🔹 К обычным запросам клиент прикрепляет access_token. Сервер быстро проверяет подпись: если всё ок, запрос проходит дальше.
🔹 Когда у access_token заканчивается срок, клиент делает отдельный запрос на эндпоинт обновления.
🔹 Сервер сверяет пришедший refresh_token с записью в базе данных. Если всё сходится, значит, запрос пришёл от реального владельца.

🔄 В этот момент и происходит ротация: сервер генерирует совершенно новую пару access и refresh токенов, а старый рефреш токен сразу аннулирует.

👌 Для пользователя сессия продлевается бесшовно и незаметно.

🤔 Но тут возникает вопрос: а что если refresh_token всё-таки украли?

🛡 Вот здесь и раскрывается главная фишка ротации для безопасности (Token Reuse Detection).

🚨 Если кто-то попытается использовать уже отработанный или устаревший refresh_token, сервер сразу видит нестыковку. Это явный сигнал о краже или повторном использовании, поэтому сервер моментально рубит всю сессию (аннулирует всю цепочку токенов пользователя) и принудительно требует залогиниться заново.

📌 Полезные рекомендации на заметку:
- Хранить токены в HttpOnly cookies.
- refresh_token необязательно делать в формате JWT, это может быть просто криптографически стойкая случайная строка.
- В БД лучше сохранять только хэш от refresh_token, а не сам токен в чистом виде.
- Обязательно гонять весь трафик через HTTPS для защиты от атак типа Man-in-the-Middle (MitM).


👨‍💻 В следующем посте покажу уже свою реализацию из кода, где я чутка оптимизировал эту схему.

#образовач

⚙️ Реализация Refresh Token

📦 Для хранения сессии я использую класс UserSession (1). В нём лежит вся ключевая информация: хэш токена, данные об устройстве, статус сессии и т.д.

🔑 При регистрации или авторизации запрос уходит в UserSessionService, где метод CreateSessionAsync (2) генерирует первичную пару access и refresh токенов.

🚦 Дальше каждый входящий запрос обрабатывается отдельным middleware - TokenRefreshMiddleware (3).

💡 И здесь кроется отличие от прошлого поста. Там клиент сам ловит ошибку 401 и отправляет повторный запрос на рефреш с фронта. Я решил избавить фронтенд от этой рутины: middleware сам достаёт оба токена из cookies и проверяет их прямо на бэкенде.

🔄 Если access_token истёк, вызывается метод RefreshSessionAsync (4) у UserSessionService, который и запускает процесс ротации.

⚙️ Вся логика ротации разделена на три возможных исхода:

🚨 1. Invalid

Токен не подошёл ни под текущий хэш, ни под предыдущий. Тут же срабатывает Token Reuse Detection (детект повторного использования старого токена). Мы отзываем сессию и блокируем доступ, защищая аккаунт от взлома.

✅ 2. ValidCurrent

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

⏳ 3. ValidGracePeriod

Тот самый исход, о котором я не говорил в прошлый раз, но без которого на практике сессия сломается.

❓ Зачем нужен Grace Period?
Когда пользователь открывает страницу, браузер может одновременно отправить 3-4 параллельных запроса. Первый запрос прилетает на бэк, успешно ротирует токен и обновляет куку. Но остальные запросы уже находятся в пути, и у них всё ещё старый refresh токен.

💀 Без Grace Period сервер посчитал бы эти параллельные запросы атакой (Invalid), и пользователя бы просто выкинуло из системы на ровном месте.

🛡 Благодаря короткому окну (буквально пара секунд) бэкенд разрешает использовать старый токен из PreviousTokenHash и спокойно отдаёт данные, не ломая активную сессию.

👌 На этом механизм ротации завершён.

👾 Полезное наблюдение: генерировать refresh токен в формате <SessionId>.<Secret>. Это позволяет при проверке моментально находить сессию по Id, а затем сверять хэш секрета.