На перший погляд блокування користувача здається простим: поставити ознаку is_blocked = true і не дозволяти наступний вхід.
Але якщо користувач уже увійшов у систему, цього недостатньо.
У нього може залишатися відкрита сесія, чинний токен, уже завантажені дозволи або запит, який почав виконуватися до моменту блокування.
Тому блокування - це не одна перевірка під час входу. Це зміна стану доступу, яка має діяти для всіх подальших захищених дій користувача.
Перевірки лише під час входу недостатньо
if ($user->is_blocked) { throw ValidationException::withMessages([ 'email' => __('auth.blocked'), ]);}Такий код правильно відхиляє нову спробу входу, але нічого не робить із сесією, яка була створена раніше.
Якщо користувач увійшов учора, а його заблокували сьогодні, наступний захищений запит може пройти без повторної перевірки стану облікового запису.
Саме тому ознаку блокування потрібно враховувати не тільки в механізмі входу.
Уже відкриті сесії потрібно обробляти окремо
Після блокування користувача вже створена сесія не зникає автоматично.
Залежно від архітектури можна видалити відомі сесії, відкликати токени або додатково перевіряти стан користувача на кожному захищеному запиті.
Найнадійніше рішення зазвичай не покладається лише на один механізм.
Стан облікового запису варто перевіряти на спільній межі доступу
public function handle( Request $request, Closure $next,): Response { $user = $request->user(); if ($user?->is_blocked) { Auth::logout(); $request->session()->invalidate(); $request->session()->regenerateToken(); abort(403); } return $next($request);Це лише спрощений приклад, але він показує головну ідею: перевірка відбувається там, де система вже знає, хто виконує захищену дію.
У реальному застосунку конкретне рішення залежить від способу автентифікації, типу сесій, токенів і правил завершення доступу.
Кеш дозволів теж може залишити застарілий доступ
У системах із ролями й дозволами частина рішень про доступ може кешуватися.
Якщо стан користувача змінився, а кеш продовжує повертати старе рішення, система може поводитися непослідовно.
Тому під час блокування потрібно розуміти, які саме дані про доступ кешуються, хто їх створює і коли вони очищаються.
Поточний запит не завжди можна зупинити посеред виконання
Є ще одна межа: запит, який уже пройшов перевірку до моменту блокування.
Якщо адміністратор блокує користувача паралельно з довгою операцією, система не завжди може безпечно перервати вже виконуваний код посеред транзакції.
Тому блокування зазвичай гарантує заборону наступних захищених дій, а не скасування всього, що вже почало виконуватися.
Блокування не повинно знищувати історичні дані
Блокування доступу і видалення даних - різні операції.
Замовлення, коментарі, платежі, повідомлення, журнали аудиту та інші історичні записи можуть бути потрібні системі й після блокування користувача.
Тому зв’язки з такими даними краще будувати так, щоб зміна стану облікового запису не ламала історію.
Розблокування не повинно повертати окремо забрані права
Користувач заблокованийРоль: editorПраво publish: забране | v Користувача розблоковано | v Роль: editorПраво publish: усе ще забранеБлокування і керування правами мають залишатися незалежними механізмами.
Якщо адміністратор окремо забрав роль або конкретне право, розблокування не повинно автоматично їх повертати.
Інакше одна дія "розблокувати" непомітно скасовує інші рішення безпеки.
Блокування перетинає автентифікацію й авторизацію, але не замінює їх
Під час входу система встановлює особу користувача. Під час захищеної дії вона вирішує, чи має цей користувач необхідні права.
Блокування додає ще одну умову: навіть правильно автентифікований користувач більше не повинен отримувати доступ.
Це продовжує ідею з окремій статті про різницю між автентифікацією та авторизацією: успішний вхід сам по собі не означає дозволу на будь-яку дію.
Що варто перевірити тестами
1. Заблокований користувач не може увійти.2. Уже відкрита сесія перестає давати доступ.3. Захищені запити перевіряють поточний стан облікового запису.4. Відкликані токени більше не працюють.5. Кеш дозволів не повертає застарілий доступ.6. Історичні дані користувача зберігаються.7. Розблокування не повертає окремо забрані права.8. Після розблокування нова сесія працює за поточними ролями й дозволами.Блокування - це зміна стану доступу, а не просто заборона входу
Якщо реалізація перевіряє is_blocked лише під час входу, вона вирішує тільки одну частину задачі.
Надійне блокування має враховувати вже відкриті сесії, токени, кеш дозволів, наступні захищені запити та поведінку після розблокування.
Водночас воно не повинно стирати історичні дані або повертати права, які були забрані окремо.
Правильна модель проста: блокування змінює можливість доступу, але не переписує історію користувача і не скасовує незалежні рішення про його права.
Заблокувати обліковий запис - означає припинити доступ, а не просто заборонити наступний вхід.
