8

次のようなコード例を見たことがありますが、これは完全に合理的です。

[Authorize(Roles = "Admin, User")] 
public class SomeController : Controller

しかし、次のような例もいくつか見ました。

[Authorize(Users = "Charles, Linus")] 
public class SomeController : Controller

なぜ私はこれをやりたいのですか？ユーザー名を事前に知っているシステムを構築したいシナリオは想像できません。

4

5 に答える 5

3

これにはいくつかの正当な使用法があり、その一例を次に示します。管理者アカウントと認証されていないアカウントを持つだけの本当に単純なサイトを構築している場合は、次のようにすることができます。

[Authorize(Users = "Admin")]

これにより、1 人のユーザーのためだけにロールを作成する手間が省けます。root アカウント (uid 0) が特定のグループではなく特別な UNIX スタイルを考えてみてください。

もう 1 つの例は、何かをテストしている使い捨てアプリケーションです。認証ページなどをテストしたいだけなら、ロールを気にする必要はありません。

もう 1 つの理由: テスト。ロールベースのフレームワークを単体テストしたくなくても、認​​証のためだけに単体テストを作成できます。(すべての人が既定のメンバーシップ プロバイダーを使用しているわけではなく、一部のメンバーシップ プロバイダーは非常に洗練されていることに注意してください。) テスト ユーザー用にハードコードされた認証を作成することで、ロール フレームワークをバイパスできます。

于 2010-02-16T15:30:47.077 に答える
1

ユーザーのハードコーディングは悪臭です。そのようなもののために役割が存在します。

編集: .net 1.0 が web.config 全体で許可/拒否権限を使用してヒットしたときのように、それらはソースの例として使用される (または少なくとも使用する必要がある) と信じています。ブログ、チュートリアル、およびサンプルでは、​​優れたプラクティスのみを使用する必要があります。

于 2010-02-16T15:27:36.643 に答える
1

私が考えることができる唯一の「正当な」理由は、バックドアを構築することです-悪意のある、または「将来のメンテナンス」の目的のいずれかです。後者は、セキュリティ リスクをもたらすため、Bad Juju です。前者はもちろんBad Jujuでもあります:)

于 2010-02-16T15:27:49.550 に答える
0

あなたがそれをすることを検討するかもしれないいくつかの理由：

  1. アプリケーションのライフサイクルは非常に短く、メンテナンスは不要です。
  2. 問題のユーザーは、(中小企業の場合のように) 十分に定義されたグループに属していない可能性があり、予想される変更はありません。（まだ非常に悪いデザインですが、前代未聞ではありません）
  3. 小規模なアプリケーションでは、グループ内の個人に対して異なる動作を必要とする複数のオーバーロードが存在する場合があります。

いずれにせよ、それは悪い設計に帰結し、あなたはそれをしたくないでしょう. しかし、インターフェイスが存在するのは、それが最も単純なレベルの制御だからです。

于 2010-02-16T15:35:26.893 に答える
0

私はデビッド・フェファーに同意します。

さらに、アプリ内で非常に具体的なアクセス許可とジョブを持つ一連のユーザーを定義できると思います-おそらくテスト目的、おそらくパフォーマンス追跡...要件がドアをノックしたときにそれがわかります。)-.

アプリケーションで使用される有効なユーザーのセットに含まれないはずの単なるグループです。:) -筋金入りの方法-

于 2010-02-16T16:23:38.017 に答える