「ユーザーは管理者かどうかを判断すべきではありません。特権またはセキュリティシステムが必要です。」

質問で使用されている例では、最小限のデータを関数に渡し、ユーザーが管理者であるかどうかを判断するための最良の方法に触れています。一般的な答えは次のとおりです。

user.isAdmin()

これにより、コメントが何度か繰り返され、何度も投票されました。

ユーザーは、管理者であるかどうかを決定するべきではありません。特権またはセキュリティシステムが必要です。クラスに密接に結合されているからといって、それをそのクラスの一部にすることは良い考えではありません。

私は答えた、

ユーザーは何も決定していません。ユーザーオブジェクト/テーブルには、各ユーザーに関するデータが格納されます。実際のユーザーは、自分に関するすべてを変更することはできません。

しかし、これは生産的ではありませんでした。明らかに、遠近法には根本的な違いがあり、それがコミュニケーションを難しくしています。誰かがuser.isAdmin（）が悪い理由を説明し、それが「正しく」行われたように見えるものの簡単なスケッチを描くことができますか？

本当に、私はそれが保護するシステムからセキュリティを分離することの利点を見ることはできません。セキュリティに関するテキストには、セキュリティを最初からシステムに組み込む必要があり、開発、展開、保守、さらには寿命のあらゆる段階で考慮する必要があると書かれています。側面にボルトで固定できるものではありません。しかし、このコメントに対するこれまでの17の賛成票は、私が重要な何かを見逃していると言っています。

ユーザーをキーとして、パーミッションを値として考えてください。

異なるコンテキストには、ユーザーごとに異なる権限があります。権限はコンテキストに関連しているため、コンテキストごとにユーザーを変更する必要があります。したがって、そのロジックを別の場所（コンテキストクラスなど）に配置し、必要に応じてアクセス許可を検索することをお勧めします。

副作用として、システムがより安全になる可能性があります。これは、関連性のない場所の管理フラグをクリアすることを忘れることができないためです。

そのコメントはひどい言葉でした。

ポイントは、ユーザーオブジェクトが、それは管理者、トライアルユーザー、スーパーユーザーまたはであるかどうかを「決定」するかどうかではないものや普通の。明らかにそれはそれらのことを決定するものではなく、あなたが実装しているソフトウェアシステム全体が決定します。ポイントは、「ユーザー」クラスがそのオブジェクトが表すプリンシパルの役割を表すべきか、またはこれが別のクラスの責任であるかどうかです。

私は元のコメントを言葉どおりに表現することを選択しませんでしたが、正当な問題の可能性を特定します。

特に、分離を保証する懸念は、認証と認可です。

認証とは、ログインしてIDを取得するプロセスを指します。それは、システムがあなたが誰であるかを知る方法であり、パーソナライゼーション、オブジェクト所有権などのようなものに使用されます。

承認とは、許可されていることを指し、これは（一般に）あなたが誰であるかによって決まりません。代わりに、ロールや権限などのセキュリティポリシーによって決定されます。これらのポリシーは、名前やメールアドレスなどを気にしません。

これら2つは、互いに直交して変化します。たとえば、OpenID / OpenAuthプロバイダーを追加して認証モデルを変更できます。また、新しいロールを追加するか、RBACからABACに変更することにより、セキュリティポリシーを変更できます。

これらすべてが1つのクラスまたは抽象化になると、リスクを軽減するための最も重要なツールの1つであるセキュリティコードが皮肉なことに高リスクになります。

私は、認証と承認があまりにも密に結合されているシステムで働いてきました。1つのシステムでは、それぞれが1つのタイプの「ロール」に対応する2つの並列ユーザーデータベースがありました。それを設計した人またはチームは、明らかに、単一の物理ユーザーが両方の役割を担っていること、複数の役割に共通する特定のアクションがあること、またはユーザーIDの衝突に問題があるとは考えていませんでした。これは明らかに極端な例ですが、作業するのは非常に苦痛でした。

MicrosoftおよびSun / Oracle（Java）は、認証および許可情報の集合体をセキュリティプリンシパルと呼びます。完璧ではありませんが、かなりうまく機能します。.NETでは、たとえば、あなたが持ってIPrincipalいる、カプセル化IIdentity前者は- ポリシー（承認）オブジェクトを、後者がある一方、アイデンティティ（認証）。あるものを別のものの中に入れるという決定に合理的に疑問を投げかけることはできますが、重要なことは、あなたが書くほとんどのコードは抽象化の1つだけのためであり、テストとリファクタリングが容易であることを意味します。

User.IsAdminフィールドに問題はありません... フィールドもある場合を除きUser.Nameます。これは、「ユーザー」の概念が適切に定義されていないことを示します。これは、残念ながら、セキュリティに関して少し遅れている開発者の間で非常によくある間違いです。通常、IDとポリシーで共有する必要があるのはユーザーIDだけです。これは、偶然ではなく、Windowsと* nixの両方のセキュリティモデルでの実装方法です。

IDとポリシーの両方をカプセル化するラッパーオブジェクトを作成することは完全に受け入れられます。たとえば、現在のユーザーがアクセスを許可されているさまざまなウィジェットまたはリンクに加えて、「hello」メッセージを表示する必要があるダッシュボード画面の作成を容易にします。このラッパーがIDおよびポリシー情報をラップするだけで、所有権を主張しない限り。言い換えれば、集約ルートとして提示されていない限り。

単純なセキュリティモデルは、YAGNIなどの理由で、新しいアプリケーションを最初に設計するときは常に良いアイデアのように見えますが、ほとんどの場合、新しい機能が追加されるので、ほとんどの場合、後で噛み付いてしまいます。

そのため、自分に最適なものがわかっている場合は、認証情報と承認情報を別々に保持します。現在の「承認」が「IsAdmin」フラグと同じくらい簡単な場合でも、認証情報と同じクラスまたはテーブルの一部でない場合は、セキュリティポリシーが必要な場合に変更すると、認証システムで再建手術を行う必要はありませんが、すでに正常に機能しています。

まあ、少なくともそれは単一の責任原則に違反しています。変更（複数の管理レベル、さらに異なるロール）があるはずです。この種の設計はかなり面倒で、維持するのが大変です。

セキュリティシステムをユーザークラスから分離する利点を検討してください。これにより、両方が単一の適切に定義された役割を持つことができます。全体的に、よりクリーンで保守しやすい設計になります。

おそらく不十分に表現された問題は、それがUserクラスに過度の重みをかけていることだと思います。いいえ、User.isAdmin()これらのコメントで提案されているように、methodを使用してもセキュリティ上の問題はありません。結局のところ、コアクラスの1つに悪意のあるコードを挿入できるほど深くコードの誰かがいると、深刻な問題が発生します。一方、Userすべてのコンテキストの管理者であるかどうかを判断することは意味がありません。フォーラムのモデレーター、投稿をフロントページに公開できる編集者、編集者が公開するコンテンツを作成できるライターなど、さまざまな役割を追加するとします。Userオブジェクトにオブジェクトを配置するアプローチでUserは、クラスに直接関係しないメソッドとその上に存在するロジックが多すぎることになります。

代わりに、さまざまな種類のアクセス許可の列挙とPermissionsManagerクラスを使用できます。おそらくPermissionsManager.userHasPermission(User, Permission)、ブール値を返すのようなメソッドを持つことができます。実際には、次のようになります（Javaの場合）：

if (!PermissionsManager.userHasPermission(user, Permissions.EDITOR)) {
  Site.renderSecurityRejectionPage();
}

これは、Railsのメソッドbefore_filterメソッドと本質的に同等であり、実世界でのこのタイプのアクセス許可チェックの例を提供します。

Object.isX（）は、オブジェクトとXの間の明確な関係を表すために使用されます。これは、たとえば次のようなブール値の結果として表現できます。

Water.isBoiling（）

Circuit.isOpen（）

User.isAdmin（）は、システムのすべてのコンテキスト内で「管理者」という単一の意味を想定します。ユーザーは、システムのあらゆる部分で管理者です。

簡単に聞こえますが、実際のプログラムはほとんどこのモデルに適合しません。ユーザーが[X]リソースを管理し、[Y]ではなく、またはより明確なタイプの管理者（[プロジェクト]管理者と[システム]管理者）。

この状況では、通常、要件の調査が必要です。クライアントがUser.isAdmin（）が実際に表す関係を必要とすることはめったにないので、明確化せずにそのようなソリューションを実装することをheします。

ポスターは単に異なる、より複雑なデザインを念頭に置いていました。 私の意見でUser.isAdmin()は、大丈夫です。後で複雑な許可モデルを導入したとしても、移動する理由はほとんどありませんUser.isAdmin()。後で、Userクラスを、ログインしているユーザーを表すオブジェクトと、ユーザーに関するデータを表す静的オブジェクトに分割できます。または、そうでないかもしれません。明日のために明日保存します。

本当に問題ない...

に問題はありませんUser.isAdmin()。私は確かにのようなものよりもそれを好む。それPermissionManager.userHasPermission(user, permissions.ADMIN)はSRPの神聖な名前でコードをより明確にせず、価値のあるものを追加しない。

私は、SRPが文字通りに少し解釈されていると思う。クラスにリッチなインターフェースを持たせることは望ましいことです。SRPは、オブジェクトが単一の責任に該当しないものはすべて、共同作業者に委任する必要があることを意味します。ユーザーの管理者ロールがブール型フィールドよりも複雑なものである場合、ユーザーオブジェクトがPermissionsManagerに委任することは非常に適切です。しかし、それは、ユーザーがisAdminメソッドを保持することも良い考えではないという意味ではありません。実際、アプリケーションが単純なものから複雑なものへと変化する場合、ユーザーオブジェクトを使用するコードを変更する必要があることを意味します。IOW、クライアントはユーザーが管理者であるかどうかの質問に答えるために本当に必要なことを知る必要はありません。

...しかし、なぜあなたは本当に知りたいのですか？

とはいえ、ユーザーがウィジェットの更新など、特定のアクションの実行を許可されているかどうかなど、他の質問に答えることができる以外は、ユーザーが管理者であるかどうかを知る必要はほとんどないようです。その場合、次のようなウィジェットのメソッドを使用したいと思いisUpdatableBy(User user)ます。

boolean isUpdatableBy(User user) {
    return user.isAdmin();
}

このように、ウィジェットは、ユーザーが更新するためにどの条件を満たす必要があるかを知る責任があり、ユーザーはそれが管理者であるかどうかを知る責任があります。この設計は、その意図を明確に伝え、その時が来たときに、より複雑なビジネスロジックに簡単に移行できるようにします。

[編集]

持っていないことUser.isAdmin()と使用していることの問題PermissionManager.userHasPermission(...)

ユーザーが管理者（または管理者ロール）であるかどうかを知りたい場合、PermissionManagerオブジェクトのメソッドを呼び出すよりもUserオブジェクトのメソッドを呼び出すことを非常に好む理由を説明するために答えに追加しようと思いました。

このユーザーが管理者であるかどうかを質問する必要がある場合は、常にUserクラスに依存すると仮定するのは公平だと思います。それはあなたが取り除くことができない依存関係です。しかし、ユーザーを別のオブジェクトに渡して質問する必要がある場合、ユーザーに既にあるオブジェクトの上にそのオブジェクトへの新しい依存関係が作成されます。質問が頻繁に聞かれる場合、それは余分な依存関係を作成する多くの場所であり、依存関係のいずれかがそれを要求する場合、変更する必要がある多くの場所です。

これを、依存関係をUserクラスに移動することと比較してください。これで、突然、クライアントコード（質問をする必要があるコードはこのユーザーadminです）が、この質問への回答方法の実装と連動していないシステムができました。許可システムは完全に自由に変更できます。変更するには、1つのクラスの1つのメソッドのみを更新する必要があります。すべてのクライアントコードは同じままです。

isAdminパーミッションサブシステムのUserクラスに依存関係を作成することを恐れて、Userにメソッドを持たないことを主張することは、1ドルをかけて1ドルを稼ぐことに似ています。確かに、Userクラスでは1つの依存関係を回避しますが、質問をする必要があるすべての場所で1つの依存関係を作成するというコストがかかります。お買い得ではありません。

この議論は、Eric Lippertのブログ投稿を思い起こさせました。これは、クラスの設計、セキュリティ、および正確さについての同様の議論の中で注目されました。

フレームワーククラスの多くが封印されているのはなぜですか？

特に、エリックはポイントを上げます：

4）安全。ポリモーフィズムのポイントは、動物のように見えるが実際はキリンであるオブジェクトを渡すことができるということです。ここには潜在的なセキュリティ問題があります。

封印されていない型のインスタンスを取るメソッドを実装するたびに、その型の潜在的に敵意のあるインスタンスに直面して堅牢になるようにそのメソッドを記述しなければなりません。悪意のあるWebページは実装をサブクラス化し、仮想メソッドをオーバーライドしてロジックを台無しにするものを実行し、それを渡すため、YOUR実装に当てはまることがわかっている不変条件に依存することはできません。クラスをシールするたびに、そのクラスが何をするかを知っているという自信を持って、そのクラスを使用するメソッドを書くことができます。

これは接線のように思えるかもしれませんが、SOLID 単一責任原則について他のポスターが提起したポイントと一致すると思います。User.IsAdminメソッドまたはプロパティを実装しない理由として、次の悪意のあるクラスを考慮してください。

public class MyUser : User
{

    public new boolean IsAdmin()
    {
        // You know it!
        return true;
    }

    // Anything else we can break today?

}

確かに、これは少しのストレッチです。IsAmdmin仮想メソッドの作成を提案する人はまだいませんが、ユーザー/ロールアーキテクチャが奇妙に複雑になった場合に起こる可能性があります。（またはそうではないかもしれません。public class Admin : User { ... }そのようなクラスには上記のコードが含まれている可能性があります。）悪意のあるバイナリを所定の場所に配置することは一般的な攻撃ベクトルではなく、不明瞭なユーザーライブラリよりも混乱の可能性がはるかに高くなります。特権エスカレーションのバグである可能性があります。最後に、悪意のあるバイナリまたはオブジェクトのインスタンスがランタイムに到達した場合、「特権またはセキュリティシステム」が同様の方法で置き換えられることを想像するのはそれほど簡単ではありません。

しかし、エリックの心を捉えて、特定の種類の脆弱なシステムにユーザーコードを配置すると、ゲームに負けただけかもしれません。

ああ、記録のために正確に言うと、質問の仮定に同意します。「ユーザーは、それが管理者であるかどうかを決定すべきではありません。システムUser.IsAdmin上でコードを実行している場合、コードを100％制御できないままにする方法は、悪い方法ですPermissions.IsAdmin(User user)。代わりに行う必要があります。

ここでの問題は次のとおりです。

if (user.isAdmin()) {
   doPriviledgedOp();
} else {
   // maybe we can anyway!
   doPriviledgedOp();
}

セキュリティを適切に設定している場合、特権メソッドは呼び出し元に十分な権限があるかどうかをチェックする必要があります。この場合、チェックは不要です。または、セキュリティに関する独自の決定を下すために、権限のないクラスを信頼していない。