それがすべての方法です。 次に、パッケージの移行により、ロール、権限、およびそれらの関係を保存するための5つのラベルがデータベースに追加されます。 ロール「admin」や「editor」が「編集投稿」を実行できるなど、すべての承認ルールはこれらのテーブルに保存されます。 通常、プロジェクトにはデータベースのコピーが多数あります。 開発者、テストベース、および本番のコピー。 その結果、これらの認可ルールはすべて、データベース間で強制的に同期されます。
実稼働データベースにルールのメインコピーが1つあり、残りがそこからすべてをコピーするいくつかのプロジェクトに出会いました。
Seederクラスを使用するという考え方（ 例 ）は、はるかに優れています。 あなただけを実行する必要があります
php artisan db:seed AuthSeeder
また、データベースに最新バージョンのルールがあります。 したがって、このシーダークラスは、一種の単一ソースの真実になります。 良いですが、このアプローチにはまだ多くの不便があります。
- Seederは、ロールと権限、およびそれらの間の接続を作成するだけでなく、古いバージョンを同期するのに十分なスマートでなければなりません。 つまり 必要に応じて、役割と権限の間のリンクを削除または作成します。
- ルールはデータベースに保存され、それらの間の一定の同期が必要です。 「編集者は投稿を編集しないで、公開するだけ」というフォームの要件が変更されるたびに、シーダーが変更され、gitベースなどでコードベースが同期され、「AuthSeederを開始するのを忘れないでください！」
- 認可ルールは複雑になる場合があります。 たとえば、パブリケーションは、編集者または管理者だけでなく、このパブリケーションの作成者も編集できます。 したがって、単純なミドルウェアの代わりに：
['middleware' => ['permission:edit posts']]
開発者は標準のlaravel承認を使用する必要があります。
class PostPolicy { public function edit(User $user, Post $post) { return $user->id == $post->owner_id || $user->hasPermissionTo('edit posts'); } }
それで、おそらく最も簡単な方法は最良ではありませんか？
それは単純に見えます：パッケージを入れて、完了した移行を開始して、行ってください。 長期的なプロジェクトサポートの観点から、これは最良の選択ではありません。
プロジェクトに通常必要なものを分析してみましょう。 シンプルなロールプレイングシステム。 ほとんどの場合、ユーザーごとに1つの役割。 管理者 まあ、多分別の編集者やモデレーター。 そして、これらの役割にはいくつかの許可があります。 最も直接的な方法で行こう！ usersテーブルに新しいフィールドを追加してください！ is_adminまたはrole 次に、 Userクラスのヘルパー数人：
class User { public function isAdmin(): bool {...} public function isEditor(): bool {...} }
今、パーミシェン。 Laravelはそれらを記述するための2つの主要な方法を提供します： ゲートとポリシー 。 私はゲートを使用します（変数に関数がある小さなトリックがまだありますが、関数型プログラミングの愛好家にとっては、これはまったくトリックではありません）：
$isAdmin = function (User $user) { return $user->isAdmin(); } $isEditorOrAdmin = function (User $user) { return $user->isAdmin() || $user->isEditor(); } Gate::define('foo-permission', $isAdmin); Gate::define('bar-permission', $isAdmin); Gate::define('editor-permission', $isEditorOrAdmin); // Complex permission Gate::define('edit-post', function(User $user, Post $post) { return $user->id == $post->owner_id || $user->isAdmin(); });
プロジェクトでユーザーごとに複数のロールが必要な場合は、 user_rolesテーブルを追加して、 Userクラスのヘルパーを変更するだけです。 *信頼パッケージのシードクラスの内容と、このコードベースの承認はほとんど同じです！ ただし、ルールはコードに単純に保存されるようになり、データベース内でルールを常に同期する必要がなくなりました。
これらのパッケージは役に立たないとは言いたくありません。 このアプローチは、クライアント自身が後でロールを設定する複雑な承認システムを備えたプロジェクトで非常に役立ちます。 動的な権限を持つプロジェクトもあります。 例：サブフォーラムのあるフォーラム。 各サブフォーラムは独自のモデレーターを持つことができ、各モデレーターはこのサブフォーラムで管理者によって定義された権限を持ちます。 別の例は、電報とそのグループです。 同じことがあります。 このようなプロジェクトには、データベースに保存された複雑な、認可システムとそのすべての問題が本当に必要です。 しかし、他のほとんどはそうではありません。
laravelのパッケージの状況は、Delphiのコンポーネントの状況と似ています（古い人は覚えています）。 彼らはためらうことなくパッケージを入れました-本当に必要かどうか。
したがって、ここで私のプロジェクトで$ a + $ bを計算する必要があります。 laravel-sumパッケージはありますか？
PS許可をおpoびしますが、正確な翻訳が見つかりませんでした。