'; var_dump(new \DateTime($tokenExpires)); echo''; + // echo '
'; var_dump(PersonalAccessToken::where('tokenable_id', $userId)->get()->toArray()[0]['expires_at']); echo'';
+ //Если токен истекает менее через 60 минут, продлеваем его на 2 часа. Ситуации, что сессия протухла, а токен продолжает жить не может случиться, так как апи запросы с фронта отправляют куку аутентификации, которая проверяется при $this->authenticate. Если она протухла, возвратится 401 ошибку.
+ // if ($token->expires_at->diffInMinutes(now()) < 60) {
+ // $token->update(
+ // [
+ // 'expires_at' => now()->addHours(2)
+ // ]
+ // );
+ // }
+
+ //Через фасад устанавливаем все значения аутентифицированного пользователя, чтобы через этот же фасад можно было и любого места в приложении их получить.
+ UserContext::setUserLogin(session()->get('_auth_login'));
+ $userGroups = session()->get('_auth_groups');
+ UserContext::setUserADGroups($userGroups);
+ UserContext::setUserEmails($userGroups);
+ UserContext::setIsAdminFlag(session()->get('is_admin'));
+ //На этапе посредника мы не проводим повторное определение ролей пользователя, это было сделано в LoginController в процессе авторизации после успешной аутентификации. Здесь мы уже берем его доступы из таблицы с токенами
+ $user = User::where('login', UserContext::getUserLogin())->first();
+ UserContext::setUserId($user->id);
+ UserContext::setUserAppPermissions($user->tokens()->latest()->first()->abilities['permissions']);
+ #Гаврилов
+ return $next($request);
+ } else {
+ //Получаем адрес предыдущей страницы, на которую хотел попасть пользователь, чтобы направить его после успешной аутентификации на этот адрес
+ $prevPageUrl = explode('/', $_SERVER['REDIRECT_URL']);
+ //Удаляем из URL редиректа пустые сегменты и сегмент с названием приложения (оно подставляется при редиректе само)
+ unset($prevPageUrl[0], $prevPageUrl[1]);
+ //Кладем в сессию адрес страницы. только если это не страница выхода, иначе после аутентификации пользователя сразу выбросит
+ session()->put('_auth_prev_page', implode('/', $prevPageUrl) == 'logout' ? '/menu' : implode('/', $prevPageUrl));
+ return redirect('/login');
+ //редирект на страницу login с сообщением об ошибке
+ }
+ } else {
+ return redirect('/login');
+ //redirect на страницу login после которой точно сессия застартует, так как это webроут, а не api
+ }
+ // return $next($request);
+ }
+}
diff --git a/app/Http/Middleware/AuthenticateMagicApi.php b/app/Http/Middleware/AuthenticateMagicApi.php
new file mode 100644
index 0000000..5571805
--- /dev/null
+++ b/app/Http/Middleware/AuthenticateMagicApi.php
@@ -0,0 +1,61 @@
+is('api/silent_token_refresh')) {
+ // return $next($request);
+ // }
+ //Если пользователь в рамках сессии обращается к api ендпоинтам из приложения, он не всегда может установить заголовок с sanctum токеном (например, переходя по ссылкке ). В этом случае, проверяем куки и устанавливаем заголовок оттуда, так как при аутентификации пользовательский логин кладется в куки. Это позволяет нам не устанвливать заголовк в каждом fetch запросе на фронте
+ if ($request->is('api/*') && ($token = $request->cookie('sanctum_token'))) {
+ $request->headers->set("Authorization", "Bearer $token");
+ }
+ //Переопределяем поведение в случае возникновения ошибки при стандартной аутентификации. Стандартное поведение перебрасывает на страницу login, мы же возвращаем 401 ошибку, так как понимаем, что пользователь обратился по api
+ //DGAVRILOV. ПОВЕДЕНИЕ, ОПИСАННОЕ ВЫШЕ, ПРИВОДИТ К ОШИБКЕ. ЕСЛИ ПОЛЬЗОВАТЕЛЬ ОТПРАВИЛ API ЗАПРОС С ФРОНТА И ЕГО СЕССИЯ ПРОТУХЛА, ВОЗВРАЩАЕТСЯ 401 ОШИБКА ВО ВКЛАДКЕ NETWORK, НО ПОЛЬЗОВАТЕЛЯ НЕ ПЕРЕБРАСЫВАЕТ НА СТРАНИЦУ /LOGIN. ЕСЛИ ПОПРАВИТЬ ПОСРЕДНИК WEB АУТЕНТИФИКАЦИИ, ТО ЭТОЙ ПРОБЛЕМЫ НЕ БУДЕТ? БУДЕТ ПЕРЕБРАСЫВАТЬ НА СТРАНИЦУ LOGIN СО СТРАНИЦЫ, ОТКУДА СОВЕРЩАЛСЯ ВЫЗО API ЕНДПОИНТА? СКОРЕЕ ВСЕГО НЕТ, НУЖНО БУДЕТ ПРИ ВЫЗОВЕ API КАК-ТО ПЕРЕХВАТЫВАТЬ 401 ОШИБКУ И ОТПРАВЛЯТЬ НА СТРАНИЦУ /LOGIN
+ try {
+ //Стандартная аутентификация по санктум токену (проверяется срок жизни)
+ $this->authenticate($request, $guards);
+ //$token = $request->user()->currentAccessToken();
+ //Если токен истекает менее через 60 минут, продлеваем его на 2 часа. Ситуации, что сессия протухла, а токен продолжает жить не может случиться, так как апи запросы с фронта отправляют куку аутентификации, которая проверяется при $this->authenticate. Если она протухла, возвратится 401 ошибку.
+ // if ($token->expires_at->diffInMinutes(now()) < 60) {
+ // $token->update(
+ // [
+ // 'expires_at' => now()->addHours(2)
+ // ]
+ // );
+ // }
+ //После успешной аутентификации Sanctum обогащаем UserService параметрами пользователя (логин, роли приложения)
+ #Гаврилов
+ //ПОКА НЕ ДОБАВЛЯЮ ГРУППЫ AD B EMAILS, ТАК КАК В WEB КОНТУРЕ ОНИ ОПРЕДЕЛЯЮТСЯ ПРИ AD АУТЕНТИФИКАЦИИ И ПОЛУЧЕННЫЕ ЗНАЧЕНИЯ СКЛАДЫВАЮТСЯ В SESSION. В API КОНТУРЕ ДОСТУПА К СЕССИИ НЕТ - ПРОВОДИТЬ AD АУТЕНТИФИКАЦИЮ НЕ ПОЛУЧИТС БЕЗ ПАРОЛЯ ПОЛЬЗОВАТЕЛЯ, КОТОРЫЙ НИГДЕ НЕ ХРАНИТСЯ. ПОЭТОМУ, ЕСЛИ ПОНАДОБИТСЯ ДОСТАВАТЬ В API КОНТУРЕ ГРУППЫ ПОЛЬЗОВАТЕЛЯ, ПРИ AD АУТЕНТИФИКАЦИИ ПОНАДОБИТСЯ КЛАСТЬ AD ГРУППЫ ПОЛЬЗОВАТЕЛЯ И ЕГО EMAILS В ПОЛЕ ABILITIES ТАБЛИЦЫ PERSONAL ACCESS TOKENS ПО АНАЛОГИИ С PERISSIONS
+ #Гаврилов
+ //НУЖНО ЛИ ОБОГАЩАТЬ USERcoNTEXT НИЖЕ, ЕСЛИ ПРИ WEB АУТЕНТИФИКАЦИИ КОНТЕКСТ УЖЕ ДОЛЖЕН БЫЛ БЫТЬ ОБОГАЩЕН. вЕРОЯТНО, ЭТО НУЖНО ДЛЯ ОБРАБОТКИ ЧИСТО API ЗАПРОСОВ (БЕЗ ВХОДА В СИСТЕМУ), НО НАДО ПРОВЕРИТЬ
+ UserContext::setUserLogin($request->user()->login);
+ UserContext::setUserAppPermissions($request->user()->currentAccessToken()->abilities['permissions']);
+ } catch (AuthenticationException $auth) {
+ if ($request->is('api/*')) {
+ return response()->json([
+ #Гаврилов
+ //СКОРРЕКТИРУЙ ИНФОРМАЦИЮ О ВОЗВРАЩАЕМОЙ ОШИБКЕ?
+ 'error' => 'Unauthenticated',
+ 'message' => 'Invalid or missing authentication token'
+ ], 401);
+ }
+
+ throw $auth;
+ }
+ return $next($request);
+ }
+}
diff --git a/app/Http/Middleware/CheckUserAppAccess.php b/app/Http/Middleware/CheckUserAppAccess.php
new file mode 100644
index 0000000..11af61c
--- /dev/null
+++ b/app/Http/Middleware/CheckUserAppAccess.php
@@ -0,0 +1,43 @@
+route()->getPrefix());
+ $moduleName = end($moduleName) ?? null;
+ if ($moduleName) {
+ if (array_key_exists($moduleName, UserContext::getUserAppPermissions()) !== false) {
+ return $next($request);
+ }
+ }
+ //Если ошибка при обращении к api ендпоинту
+ if ($request->expectsJson()) {
+ return response()->json(['message' => "Ошибка! Приложение недоступно"], 403);
+ //Если ошибка при обращении к web роуту
+ } else {
+ #Гаврилов
+ //ЕСЛИ ВЫЗЫВАЕТСЯ WEB РОУТ НЕ С ФРОНТА, ТО ПРОИСХОДИТ РЕДИРЕКТ БЕЗ УКАЗАНИЯ ТЕКСТА ОШИБКИ. нАПРИМЕР, ПРИ РЕДИРЕКТЕ НИЖЕ НА СТРАНИЦУ МЕНЮ, ПОЛЬЗОВАТЕЛЬ НЕ УВИДИТ НИКАКОГО ОПОВЕЩЕНИЯ ОБ ОШИБКЕ
+ //ЭТУ ПРОБЛЕМУ Я ИСПРАВЛЯЛ, ЧЕРЕЗ ГЕНЕРАЦИЮ НОТИФИКАЦИЙ НА БЭКЕ И ДОБАВЛЕНИЯ ИХ В ОПРЕДЕЛЕННУЮ ОЧЕРЕДЬ REDIS, КОТОРУЮ ЧИТАЕТ КАЖДАЯ СТРАНИЦА ПРИ ПЕРВИЧНОМ РЕНДЕРИНГЕ. НАДО ПОСМОТРЕТЬ ГДЕ Я УЖЕ ТАКОЕ РЕАЛИЗОВЫВАЛ
+ return redirect('/menu');
+ }
+ }
+}
diff --git a/app/Http/Middleware/CheckUserPermission.php b/app/Http/Middleware/CheckUserPermission.php
new file mode 100644
index 0000000..b6cbf47
--- /dev/null
+++ b/app/Http/Middleware/CheckUserPermission.php
@@ -0,0 +1,67 @@
+route()->getPrefix());
+ $moduleName = end($moduleName) ?? null;
+
+ if ($moduleName) {
+ if (array_key_exists($moduleName, UserContext::getUserAppPermissions()) !== false) {
+ if (in_array($userPermissions[$moduleName], $accessRoles)) {
+ return $next($request);
+ }
+ // else {
+ // return redirect('/menu');
+ // #Гаврилов
+ // //РЕДИРЕКТ НА СТРАНИЦУ 403
+ // }
+ }
+ // else {
+ // return redirect('/menu');
+ // #Гаврилов
+ // //РЕДИРЕКТ НА СТРАНИЦУ 403
+ // //redirect();
+ // }
+ }
+ // else {
+ // return redirect('/menu');
+ // #Гаврилов
+ // //КУДА РЕДИРЕКТИТЬ или что возвращать, если имя модуля не определено?
+ // }
+
+ //Если ошибка при обращении к api ендпоинту
+ if ($request->expectsJson()) {
+ return response()->json(['message' => "Ошибка! Функционал недоступен для вашей роли"], 403);
+ //Если ошибка при обращении к web роуту
+ } else {
+ #Гаврилов
+ //ЕСЛИ ВЫЗЫВАЕТСЯ WEB РОУТ НЕ С ФРОНТА, ТО ПРОИСХОДИТ РЕДИРЕКТ БЕЗ УКАЗАНИЯ ТЕКСТА ОШИБКИ. нАПРИМЕР, ПРИ РЕДИРЕКТЕ НИЖЕ НА СТРАНИЦУ МЕНЮ, ПОЛЬЗОВАТЕЛЬ НЕ УВИДИТ НИКАКОГО ОПОВЕЩЕНИЯ ОБ ОШИБКЕ.
+ //ЭТУ ПРОБЛЕМУ Я ИСПРАВЛЯЛ, ЧЕРЕЗ ГЕНЕРАЦИЮ НОТИФИКАЦИЙ НА БЭКЕ И ДОБАВЛЕНИЯ ИХ В ОПРЕДЕЛЕННУЮ ОЧЕРЕДЬ REDIS, КОТОРУЮ ЧИТАЕТ КАЖДАЯ СТРАНИЦА ПРИ ПЕРВИЧНОМ РЕНДЕРИНГЕ. НАДО ПОСМОТРЕТЬ ГДЕ Я УЖЕ ТАКОЕ РЕАЛИЗОВЫВАЛ
+ return redirect('/menu');
+ }
+ #Гаврилов
+ //РЕДИРЕКТ НА СТРАНИЦУ 403
+ }
+}
diff --git a/app/Http/Middleware/VerifyCsrfToken.php b/app/Http/Middleware/VerifyCsrfToken.php
new file mode 100644
index 0000000..0b8c917
--- /dev/null
+++ b/app/Http/Middleware/VerifyCsrfToken.php
@@ -0,0 +1,19 @@
+
+ */
+ protected $except = [
+ //
+ '/access/*',
+ '/access',
+ ];
+}
diff --git a/app/Models/User.php b/app/Models/User.php
index 749c7b7..a967f84 100644
--- a/app/Models/User.php
+++ b/app/Models/User.php
@@ -6,43 +6,45 @@ namespace App\Models;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
+use Laravel\Sanctum\HasApiTokens;
class User extends Authenticatable
{
- /** @use HasFactory<\Database\Factories\UserFactory> */
- use HasFactory, Notifiable;
+ use HasApiTokens, HasFactory, Notifiable;
/**
* The attributes that are mass assignable.
*
- * @var list