Параллельная авторизация

[Jampire]

Из беседы в тг (пример с глобальным скоупом лишь для подсвечивания проблемы):
Есть модель Subscriber, каждый авторизованный пользователь может видеть только своих подписчиков (связь subsribers.user_id на users.id). Неавторизованному пользователю ресурс недоступен.
Для соблюдения этого требования реализован глобальный скоуп:

class UserScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        if ($user = request()->user()) {
            $builder->whereBelongsTo($user);
        }
    }
}

// Models/Subscriber

public function user(): BelongsTo
{
    return $this->belongsTo(User::class);
}

protected static function booted(): void
{
    static::addGlobalScope(new UserScope());
}

Пользователь авторизуется одновременно на основном сайте (user_id=11) и в админке. При запросе ресурса SubscriberResource, админ с якобы полным доступом, увидит результат следующего запроса:

select
  *
from
  `subscribers`
where
  (
    `id` LIKE '%veh%'
    or `email` LIKE '%veh%'
    or `first_name` LIKE '%veh%'
    or `last_name` LIKE '%veh%'
  )
  and `subscribers`.`deleted_at` is null
  and `subscribers`.`user_id` in (11)
order by
  `id` desc
limit
  10 offset 0

and `subscribers`.`user_id` in (11) - сработал global scope.
Конечно, есть решения. Например, переопределить query в ресурсах:

// SubscriberResource
public function query(): Builder
{
    return parent::query()
        ->withoutGlobalScope(UserScope::class);
}

Но об этом надо помнить при создании новых тегов, которые определяют свои билдеры. Нужно следить, чтобы они использовали билдер ресурса, а не билдер модели. А если теги реализует другой программист или теги пишутся через полгода после создания ресурса? Появляется косвенная несогласованность между тегами ресурса и билдером ресурса.

Но опять же, данный пример лишь лакмусовая бумажка, чтобы подсветить проблему: муншайну доступен авторизованный пользователь основного приложения. Зачем? Админка должна работать только с авторизированным админом. Если, например, установить муншайн на другой домен, этой проблемы не будет: request()->user() всегда будет возвращать null.

[Jampire]

Возвращать муншайн пользователя из request()->user() тоже нельзя. Тогда при загрузке ресурса в админке будет ошибка: Call to undefined relationship [moonshineUser] on model [Subscriber]. Оно и понятно почему. Может показаться, что для избежание этой проблемы в глобальном скоупе нужно ставить проверку на муншайн пользователя:

$user = request()->user();
if ($user && !$user instanceof MoonshineUser) {
    $builder->whereBelongsTo($user);
}

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

[lee-to]

Смотрите в данном примере вы допускаете архитектурную ошибку завязывая глобальный скоуп на реквест и желание использовать его везде!

Если мы переопределим муншайн и сделаем дефолтный guard moonshine то ваш скоуп также не будет работать так как вернет объект с moonshine юзером

Если вы хотите чтобы мы совсем перестали использовать guard Laravel то здесь я комментарировать не буду

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

Решение вашего подхода с глобальным скоупом в муншайн решается через метод query в ресурсе, вы можете его отключить

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

Ну и в целом я не особо понял цель дискуссии, переопределять гуард во всех реквестах в муншайн, ну тут опять ваш скоуп вызовет конфликт, избавляться от ларавел системы аутентификации с возможностью переключения между guard тоже решение которое не найдет реализации и не имеет смысла, поэтому как бы странная тема поднята, но очень интересная)

[Jampire]

Как я уже отписал в тг, никаких проблем с консолью не будет. Консоль не должна в принципе иметь доступ к системе авторизации пользователя, если пользователь не взаимодействует с консолью на прямую. В экспорт передаются уже подготовленные данные, с которыми проведены уже все проверки по безопасности.

Давайте выкенем из головы этот скоуп. Он тут приведен лишь для того, чтобы подсветить и наглядно продемонстрировать проблему. А проблема в том, что если админ одновременно авторизован и в муншайн, и в основном приложении, то муншайн получает доступ к объекту модели User основного приложения. Такого быть не должно. Муншайн должен иметь доступ только к объекту модели MoonshineUser и частично к объекту модели User, если будет реализована возможность имперсонализации действий в админке.

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

Я нигде и ни разу не предлагал избавляться от системы авторизации ларавел. Я предлагаю заблокировать муншайну возможность получить информацию об авторизованном пользователе основного приложения (зачем он ему, если у него свой гуард). А именно, при попытки вызова любого из подобных методов (в основном приложении из контекста муншайн):

request()->user();
auth()->user();

муншайну должен возвращаться null.

[Jampire]

@lee-to
Нашел отличный пример. Сам муншайн, ничего лишнего, чтобы взгляд не размывался.

Итак, имеем пользователя, у которого есть аккаунт на основном сайте и в админке. По записи в таблицах users и moonshine_users. Причем в админке пользователь имеет следующие данные:

id: 1,
name: Master,
email: [email protected]

а в таблице users такие данные:

id: 11,
name: Jampire,
email: [email protected]

Пользователь совершает вход на основной сайт и в админку (с двух разных табов браузера) и в админке заходит в свой профайл: custom_page/profile. И вот какую картину мы наблюдаем в телескопе:

Согласен, можно придраться к тому, как реализован телескоп. Но вот как объяснить вот это:

Зачем при загрузке профайла админа муншайн делает бессмысленный запрос в таблицу users?

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

[lee-to]

Спасибо, пофиксим

@lee-to

Нашел отличный пример. Сам муншайн, ничего лишнего, чтобы взгляд не размывался.

Итак, имеем пользователя, у которого есть аккаунт на основном сайте и в админке. По записи в таблицах users и moonshine_users. Причем в админке пользователь имеет следующие данные:

id: 1,

name: Master,

email: [email protected]

а в таблице users такие данные:

id: 11,

name: Jampire,

email: [email protected]

Пользователь совершает вход на основной сайт и в админку (с двух разных табов браузера) и в админке заходит в свой профайл: custom_page/profile. И вот какую картину мы наблюдаем в телескопе:

Согласен, можно придраться к тому, как реализован телескоп. Но вот как объяснить вот это:

Зачем при загрузке профайла админа муншайн делает бессмысленный запрос в таблицу users?

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