в доку бы не полез. лень

правильно

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

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

то есть это нормально других людей просить за себя смотреть в доку?

скажи, это было в доке?

скажи, это было в доке?

через запятую не видел

скажи, это было в доке?

там обычный пример Route::put('post/{id}', function ($id) { // })->middleware('role:editor');

какой пакет юзаешь для ролей?

какой пакет юзаешь для ролей?

из коробки всё юзаю

Есть бд. В бд есть таблица с фильмами, странами (1 ко многим), студиями(1 ко ногим), жанрами (многие ко многим), актёрами (многие ко многим). Нужно получить список фильмов с определёнными странами, студиями, жанрами и актёрами. Со связями 1 ко многим легче - т.к. фильмы и идентификаторы находятся в 1 таблице. Но кол-во выбранных стран и студий может разниться . Делать несколько запросов в бд и совмещать результаты? Например: $films = array(); foreach ($counties as $country) { $films = array_merge ($films, Films::where('country_id', $country) } Выходит очень дофига запросов к бд. А если посмотреть на то что ещё есть связи многие ко многим дак это вообще печаль получается, ибо связь с основной таблицей там имется только через вспомогательные по ключам. При этом всём нужно всё это дело сортировать по дате / году выпуска / алфавиту / рейтингу и т.п. Вроде как в ларавеле есть функции облегчающие и оптимизирующие всё это дело. Подскажите пожалуйста как это всё грамотно сделать?

role:admin,manager

ну кстати с таким вариантом если у админа нет менеджера в ролях то не пускает)

и просто менеджера тогда не должно пускать...

и просто менеджера тогда не должно пускать...

пускает)

тогда и просто админа должно пускать...

тогда и просто админа должно пускать...

меняю местами и по разному работает 'role:admin,manager']

если менагер первый то манагера пускает а просто админа нет и наоборот если админ первый то просто манагера не пускает)

ну тогда делай как все нормальные делают. либо используй can: либо пиши свои миддлвары.

role и так его мидл

role и так его мидл

+

Есть бд. В бд есть таблица с фильмами, странами (1 ко многим), студиями(1 ко ногим), жанрами (многие ко многим), актёрами (многие ко многим). Нужно получить список фильмов с определёнными странами, студиями, жанрами и актёрами. Со связями 1 ко многим легче - т.к. фильмы и идентификаторы находятся в 1 таблице. Но кол-во выбранных стран и студий может разниться . Делать несколько запросов в бд и совмещать результаты? Например: $films = array(); foreach ($counties as $country) { $films = array_merge ($films, Films::where('country_id', $country) } Выходит очень дофига запросов к бд. А если посмотреть на то что ещё есть связи многие ко многим дак это вообще печаль получается, ибо связь с основной таблицей там имется только через вспомогательные по ключам. При этом всём нужно всё это дело сортировать по дате / году выпуска / алфавиту / рейтингу и т.п. Вроде как в ларавеле есть функции облегчающие и оптимизирующие всё это дело. Подскажите пожалуйста как это всё грамотно сделать?

Film::whereHas(....).....

@kardashov ты лучше на основании ролей определи абилки (или политики) и юзай can

role и так его мидл

хм.. да? т.е. он написал миддлварку и не знает как ее юзать?

Film::whereHas('countries', function($query) use ($countriesIds) { $query->whereIn('id', $countriesIds); })->whereHas('genres', ....)....

хм.. да? т.е. он написал миддлварку и не знает как ее юзать?

похоже на то)

я и так слишком низкого мнения о людях.. зачем его еще ниже делать...

сделай тут перед id dd($role);

там очевидно надо implode сделать вроде.

и проверять кучу ролей. но can лучше

там очевидно надо implode сделать вроде.

explode только наверное

дада. вечно путаю

у меня api как я can смогу юзать?

public function handle($request, Closure $next, array $roles) попробуй и сделай dd($roles)

Film::whereHas('countries', function($query) use ($countriesIds) { $query->whereIn('id', $countriesIds); })->whereHas('genres', ....)....

Хмм, интересно, можно просто массив передать($countriesIds)? Вот только жанры в другой таблице лежат, many to many же - таблицы ganres и ganre_film

всё равно, там через связь вытаскивается

у меня api как я can смогу юзать?

а какая разница апи или не апи?

просто массив да

public function handle($request, Closure $next, array $roles) попробуй и сделай dd($roles)

Type error: Argument 3 passed to App\Http\Middleware\OwnerMiddleware::handle() must be of the type array, string given, called in

ну тогда верни стринг и делай explode

а какая разница апи или не апи?

я к сожалению не видел реализации с can, посмотрю тогда)

всё равно, там через связь вытаскивается

любопытно, спасибо большое за помощь. В итоге это через 1 запрос выполнится?

любопытно, спасибо большое за помощь. В итоге это через 1 запрос выполнится?

а вот не знаю чото

ну тогда верни стринг и делай explode

так в $role приходит 1 роль только а не все

ты dd($role); делал и там одна роль?

ты dd($role); делал и там одна роль?

ага

в каом то проекте я делал мидлварю с ролями, щас попробую вспомнить где и посмотрю

а вот не знаю чото

пхпмуадмин пишет логи sql запросов? Можно от туда посмотреть

смотри через дебагбар

public function handle($request, Closure $next, ...$guards)

вот вроде как надо делать

так в $role приходит 1 роль только а не все

в варианте role:foo,bar тебе придет "foo,bar" и надо самому разбивать же

вот вроде как надо делать

ну кстати да) массив получается

в варианте role:foo,bar тебе придет "foo,bar" и надо самому разбивать же

глянь выше. вроде ларка умеет сама раскидывать по параметрам

а тьфу блин, я забыл про вариант с ...

так и делал у себя

ну дальше всё понятно уже как делать)

а что вы юзаете для ролей?

примерно то же самое

примерно то же самое

а пермишены?

хотя у меня в последних проектах кроме роли админа ничего не было, поэтому там намного проще) у юзера is_admin поле и всё

а пермишены?

они почти никогда не нужны

они почти никогда не нужны

а вот с ролями лучше держать массив ролей у юзера или одну роль? как тут правильнее?

как просит продакт оунер

https://github.com/romanbican/roles - вот один раз юзал пакет, но в итоге очень мало что из него использовал. Да и давно это было. И пакет сам по всей видимости уже не поддерживается

а вот с ролями лучше держать массив ролей у юзера или одну роль? как тут правильнее?

правильнее так как требует твоя бизнес логика

какую авторизацию и т.д.

топлю за bouncer

но сам какого то хера юзаю laratrust

как просит продакт оунер

а если ты фрилансер и ты сам себя просишь?)

фигня все эти пакеты. или юзать половину не будешь или переделаешь половину под себя в итоге

а я entrust юзал )

а если ты фрилансер и ты сам себя просишь?)

значит ты продакт оунер. просто говоря про бизнес-логику... бизнес логика помоему практически никогда не влияет на авторизацию. это совсем две разные вещи

которые почти не прикасаются

значит ты продакт оунер. просто говоря про бизнес-логику... бизнес логика помоему практически никогда не влияет на авторизацию. это совсем две разные вещи

видимо мы по разному понимаем этот термин тогда

фигня все эти пакеты. или юзать половину не будешь или переделаешь половину под себя в итоге

вот тут правда. не надо юзать эти пакеты, в которых шиш кода..

видимо мы по разному понимаем этот термин тогда

есть заказ, есть возможность его отменить. сам заказ вообще не знает кто его может отменить. единственное что он может - реализовать метод cancel

есть заказ, есть возможность его отменить. сам заказ вообще не знает кто его может отменить. единственное что он может - реализовать метод cancel

тебе говорят что отменять заказы могут только менеджер ведущий клиента и директор на всякий случай. это не бизнес логика?

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

кто что может с ним делать - это параллельная вселенная

RBAC и есть часть БЛ

бл - " совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций."

кто что может с ним делать - это параллельная вселенная

контроль доста это те самые ограничения операций. на равне с правилами валидации и т.д. а ты со своим DDD в вакууме иде лесом)

ну для меня "моя бизнес-логика" и RBAC - это вообще разные вещи. тупо по принципу SRP.

но я могу быть неправ

вообще говоря спор ниочем. что называть БЛ - чисто БЛ или еще и авторизацию - смысла мало.

А вот в чем смысл есть - это где авторизацию хранить. в Application(Service) layer или в Domain layer. Для меня очевидно что в первом.

RBAC и есть часть БЛ

что скажешь? :)

в DDD авторизация думаю на слое приложения а не домена находится

в DDD авторизация думаю на слое приложения а не домена находится

вово

что скажешь? :)

Допил пиво, вышел из бара, чуть позже гляну :)

поподробнее с этого момента

просто тут у каждого свое мнение, один топит за DDD, другой понимает иначе

про авторизацию на слое приложения

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

меня тут чот все начали называть адептом DDD :) хотя я по DDD ни одного приложения не сделал...

про авторизацию на слое приложения

Заказ не должен задумываться о том кто может его отменить

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