Вам действительно нужны entrust или laravel-permission для реализации вашей авторизации?

[AEP]

Толковый пост. Статическая бизнес-логика должна быть в коде, а не в базе данных. Относится не только к PHP и Laravel, а вообще к любому фреймворку. И не только к системе прав пользователей.

[1ax3l]

Чем отличается ваш пост от этого?

[Adelf]

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

[UksusoFF]

Во всех этих пакетах печально то что нельзя пермишенны для анонимусов.
Хотя вроде с выходом 5.7 могло что-то поменятся.

[avraam_linkoln]

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

[mykolaim]

Идея использование Seeder класса(пример) намного лучше.

А почему вы не расматривате вариант вынести создание ролей в миграцию? При таком подходе у всех разработчиков будет актуальное состояние данных в БД.

[Adelf]

Это, кстати, хороший вариант :) но немного холиварный. Не по себе мне миграции использовать не для изменения структуры бд. Но, возможно, я не прав.

[JhaoDa]

Сиды предназначены только для тестовых данных. Решение в виде миграция очень даже нормальное, особенно с учётом того, что альтернативой является запиливание минимального интерфейса для управления всей авторизационной кухней, даже если это просто создание новой роли.
Я юзаю миграции для подобного рода «фундаментальных» данных.

[Adelf]

Ну… прям опровергнуть полностью ваш подход мне нечем. всякие SRP приплетать тут не очень умно наверно. Могу лишь сказать, что один из пакетов неявно рекомендует именно сиды — github.com/spatie/laravel-permission#database-seeding

[JhaoDa]

Адептусы Святого Шпателя не есть истина в последней инстанции, ибо Великая Книга прямо говорит нам:

Laravel includes a simple method of seeding your database with test data using seed classes.

[Adelf]

Могу лишь согласиться. Так написано прямо начиная с 4.2, я проверил :)
А мы в своих проектах в миграциях держали лишь структурные изменения. В сидах же лежали умные классы, которые любые старые наборы изначальных данных приводили к нужному свежему набору.
Так удобнее… поскольку сид можно было менять. а вот миграцию будь добр каждый раз создай новую.
Похоливарить можно, но нет смысла.

[hzone]

По мне, так policy за глаза хватет, когда 1 пользователь = 1 роль.

Для чего-то сложного, типа роли+права, по хорошему надо писать пакет под конкретный проект (в принципе ничего сложного), — на то и лара.

Выскажу своёё фи с точки зрения «из коробки» — из коробки оно хорошо в 2х случаях:
а) оно вписывается в архитектуру приложения и будет востребовано (основной параметр)
б) вы «буржуй» и думаете в ИХ ключе понимания строения вселенной. Поясню. Русскоговорящие (основной язык архитектора — Русский) думают несколько сложнее буржуев, так как сам язык сложнее. В следствии чего решения более простые, масштабируемые (например пакет настолько удобный, что переносится от проекта к проекту; смотрим на Сову и удивляемся её живучести), и либо используют механику (в данном случае лары) либо вообще настолько простые, что выдают требуемый результат без использования той же лары, средствами основного языка.

Как-то…