4

私はCatalystを使用してCatalyst::Plugin::Authenticationおり Catalyst::Plugin::Authorization::Roles、モデルに属性を追加するためのより良い方法があるかどうか疑問に思っています。

各ユーザーは 1 つまたは複数の会社にアクセスできますが、一度に 1 つのプライマリ (現在の) 会社が常に存在します。許可リストはデータベースに保存され、データベースへのアクセスは主に を通じて行われDBICます。

私の最初の傾向は、現在の会社を持っているのはユーザーであり、したがってそれをユーザーモデルの一部として置くことです: ユーザーパッケージに " sub company { … }" を与えて、ユーザーの現在の会社を取得/設定します。データベースのチェックはかなり簡単です。$self->search_related" " (ユーザー モデルによって継承される DBIC メソッド) を使用するだけです。

私が遭遇する問題は次のとおりです。

  • 現在の会社はリクエスト間で保持する必要がありますが、データベースには保存したくありません (このセッションの間のみ保持する必要があります)。自然な場所はセッションです…</li>
  • データベース内のリストを無視して、任意のroot会社として行動できる、 Unix の に似た役割があります。この役割の確認はデータベースを介して行うことができますが、アプリ内の他のすべての場所で 友人が使用されています。$c->assert_user_role

モデルを可能な限り Catalyst に依存しないようにするのが最善であると聞いています。モデルが を操作するのもかなり奇妙に思え $c->sessionます。

もちろん、これらのチェックをコントローラーに移動して、コントローラーが送信するものをモデルに受け入れるようにすることもできますが、それは DRY にかなり違反しており、チェックの 1 つをどこかに忘れるとセキュリティ上の問題が発生するだけです。

助言がありますか？それとも肩をすくめて先に進み、モデルでそれを行いますか?

ありがとうございます。いいタイトルが思いつかなくてすみません。

4

1 に答える 1

2

重要なのは、リクエストごとにモデル クラスのインスタンスを作成し、必要なリクエストの部分を渡すことです。この場合、おそらくベースの結果セットを渡したいでしょう。モデルは を介し​​てすべてのデータベース呼び出しを$self->resultset->...行い、現在のユーザーに対して「そのまま機能」します。(現在のユーザーが root の場合は、を渡すだけです$schema->resultset("Foo")。現在のユーザーが他のユーザーの場合は、を渡し$schema->resultset("Foo")->stuff_that_can_be_seen_by($c->user)ます。モデルは気にしなくなります。)

これについていくつかのスライドがありますが、それらは非常に時代遅れです:

http://www.jrock.us/doqueue-grr/slide95c.html#end

（直前と直後のものも参照してください。）

制限付きの結果セットと Web ACL は直交していることに注意してください。モデルをできるだけ厳密にしたい (コードが指示したとしても、アプリが望ましくないことを誤って実行できないようにするため) が、さまざまな Web のみの詳細をエンコードする必要があります。 ACL。(「このページを表示することは許可されていません。」は、「すべてのユーザーではなく、自分のオブジェクトのみを削除できます」とは異なります。ACL は最初のケースを処理し、制限された結果セットは 2 番目のケースを処理します$rs->delete。が制限されているため、データベース内のすべてを削除したわけではありません。削除権限のあるものだけを削除しました。便利です!)

于 2009-09-01T18:27:07.980 に答える