Имам традиционно уеб приложение, което има редица различни типове потребители и всеки тип потребител има свой собствен защитник за удостоверяване.
'guards' => [
'web' => [
'driver' => 'session',
'provider' => 'users',
],
'admin' => [
'driver' => 'session',
'provider' => 'admin',
],
'timekeeper' => [
'driver' => 'session',
'provider' => 'timekeeper',
],
'api' => [
'driver' => 'token',
'provider' => 'users',
],
],
Повечето мои потребители се удостоверяват с помощта на „уеб“ защитата, но администраторите и хронометристите използват своя собствена защита, която е прикрепена към подходящ потребителски доставчик.
Това е добре, докато не опитам да използвам порти за удостоверяване. Ако удостоверя автентичността на потребител срещу защитата по подразбиране на системата (напр. „уеб“), тогава вратите работят според очакванията. Ако обаче се удостоверя срещу който и да е друг пазач, тогава всички Gate::allows(...)
повиквания се ОТКАЗВАТ.
Дори следната способност е отказана:
Gate::define('read', function ($user) {
return true;
});
Предполага се, че това се дължи на ред 284-286 в Illuminate\Auth\Access\Gate:
if (! $user = $this->resolveUser()) {
return false;
}
Доколкото виждам, моите възможности са:
- Върнете се към използването на единичен „уеб“ пазач, с потребителски доставчик, който може да намери всеки тип потребител (но не съм сигурен как ще работи това, ако започна да използвам API успоредно)
- По някакъв начин задайте защитата по подразбиране по време на изпълнение, в зависимост от типа на текущия потребител. (В момента е зададено в конфигурационния файл)
- Инжектирайте по някакъв начин различен потребителски преобразувател във фасадата на Gate (отново, в зависимост от типа на текущия потребител)
Нито едно от тях обаче не изглежда интуитивно. Изпускам ли нещо?