Laravel ограничить содержание в зависимости от клиента / пользователя / арендатора

Question

Я попал в дилемму, чтобы найти какую-то логику c, чтобы ограничить доступ пользователей к контенту в той же модели. Например, поставщик может видеть только товары, которые он поставляет, а покупатель может видеть только продукт, который он покупает. (примечание: у каждого продукта может быть несколько поставщиков или клиентов. Мы называем id узлом продукта)

Теперь у меня установлено отношение, что продукт принадлежит многим поставщикам, а продукт принадлежит нескольким клиентам.

В настоящее время у меня есть роли и разрешения spat ie на моем сайте, что отлично подходит для 1 арендатора (в основном, для нашего офиса (50-150 пользователей)). Это не проблема, если пользователь нашего офиса может видеть информацию о нескольких клиентах или продуктах, но проблема начинается, когда клиент входит в систему. Я хочу показать только цену продукта или данные, которые ему принадлежат. Это большая нет, нет, чтобы увидеть какие-либо другие данные клиента или поставщика.

Я посмотрел мультитенантную реализацию, но я считаю, что это не покрыло бы мои потребности.

Я прошу прощения, если я что-то пропустил, но я стараюсь обеспечить максимальную безопасность данных.

Не могли бы вы пролить свет на эту дилемму и направить меня на правильный путь?

Большое спасибо за ваш вклад!

Answer 1

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

Примите следующее область действия:

<?php
namespace App\Scopes;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Scope;
use Illuminate\Support\Facades\Auth;

class CustomerOwnedScope implements Scope {
    public function apply(Builder $builder, Model $model) {
        if (Auth::guard('customer')->check()) {
            $builder->where('customer_id', '=', Auth::guard('customer')->id);
        }
    }

    public function extend(Builder $builder) {
        $this->addWithoutCustomer($builder);
    }

    protected function addWithoutCustomer(Builder $builder) {
        $builder->macro('withoutCustomer', function (Builder $builder) {
            return $builder->withoutGlobalScope($this);
        });
    }
}

Любая модель, имеющая эту область действия, автоматически добавит условие WHERE customer_id = ?, где ? - это идентификатор текущего пользователя, прошедшего проверку подлинности, если он прошел проверку подлинности. Предполагая, что вы используете Laravel auth, это избавит вас от необходимости делать что-либо, определяющее c для достижения вашей цели.

Он также добавляет область действия withoutCustomer(), которая препятствует выполнению предложения where. добавлено.

Самый простой способ добавить это к модели, принадлежащей клиенту, - создать себе черту (беспокойство), например, так:

<?php
namespace App\Concerns;

use App\Scopes\CustomerOwnedScope;

trait OwnedByCustomer {
    public static function bootOwnedByCustomer() {
        static::addGlobalScope(new CustomerOwnedScope);
    }

    public function customer() {
        $this->belongsTo(Customer::class, 'customer_id');
    }
}

Это добавит отношения с клиентом. а также добавить область для автоматического запроса, основанного на текущем клиенте.

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

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

Я должен добавить, что приведенный выше код взят из статьи, которую я написал на тему m ulti-tenancy, особенно часть о работе с арендаторами в единой базе данных. Если вы хотите, вы можете прочитать это здесь: https://ollieread.com/articles/laravel-multi-tenancy-avoiding-over-engineering#single -database