3

皆さん、これについてアドバイスが必要です...

ユーザーがアプリケーションに対して持つことができる特定のレベルの制御のために、データベースに特定の権限が設定されています。無効、読み取り専用、および編集。

私の質問は次のとおりです:ページのフォーム要素に適用されるアクセス許可を処理するためのより一般的な/より良い方法はありますか?

これをさまざまな方法で処理した経験がある人はいますか?

編集：

セキュリティが必要な各レイヤーに定数を追加し、コントロールがオンになっているフォームから定数を受け入れ、ブール値を返してコントロールを有効/無効にする IsAuthorized 関数をユーザークラスに追加する可能性について考えました。すべてのフォームのセキュリティを変更する必要がある場合に、ヒットしなければならない場所の数を本当に減らします。

乾杯！

4

4 に答える 4

3

ここで少しトピックから外れて申し訳ありませんが、私の間違いから学んでください：

私が開発していたときに単純な Web アプリがあり、3 つのレベルのセキュリティをセットアップすると考えていました: 制限付き読み取り専用 (パブリック)、読み取り制限付き書き込み (ユーザー)、読み取り/書き込み (管理者)。users テーブルには一定レベルのセキュリティがあり、すべてが正常に機能していました...プロジェクトが成長するにつれて、セキュリティレベルをより細かく制御する必要が生じるまで。それはすべて、プログラムの 1 つの領域でユーザー制御以上のものを必要としているが、完全な管理者制御は必要としていないユーザーから始まりました。

私がすべきだったのは、最初は必要ありませんでしたが、より細かく制御できる拡張可能なシステムをセットアップすることでした。これでかなりの時間を節約できたでしょう。

于 2008-11-11T23:01:48.480 に答える
2

あなたが考えているよりも多くの可能性があると思います。

  • 非表示/表示 - フィールドが表示されるかどうか
  • Blanked/System/Unchanged - システムが最初に値を空白に設定するか、ビジネス ルールによって提供される値に設定するか、またはそのままにするか
  • 読み取り専用/編集可能 - ユーザーは値を変更できますか
  • Required/LeaveBlank/Optional - 空白にしないことが必須のフィールド、または最初から空白であると仮定して空白のままにすることができるフィールド、またはオプションであり、どのような場合でも空白にすることができるか

また、決定を下すには多くの要因を考慮する必要があります

  • ロール - 通常、ユーザーには 1 つ以上のロールがあり、それらのロールはさまざまな可能性を許可または禁止できます
  • ステータス - 問題のオブジェクトのステータスは、多くの場合、ロールに関係なく編集可能なフィールドを制御します
  • オブジェクト - 多くの場合、オブジェクト自体の値によって、そのステータスだけでなく、何がいつ許可されるかが決まります
  • タスク - 編集作業は、読み取りと編集だけにとどまらない場合があります
  • セクション - オブジェクトまたは画面のセクション全体の設定を制御したいことがよくあります。すべてのコントロールはこれらの設定を継承しますが、必要に応じて個別にオーバーライドできます

実装？まず、ページのライフサイクルがどのように処理されるかについて明確なビジョンを持っていることを確認してください。私の場合はだいたいこんな感じです。

  • 彼らが編集しているオブジェクトを、通常はセッション状態から取得する
  • これが初めてページをロードする場合は、ドロップダウンに選択肢を入力します。これは通常、1 回だけ実行される一般的なプロセスです。
  • これがポストバックの場合は、コントロールから値を読み取って編集中のオブジェクトを更新します
  • ボタンクリックなどの処理イベント
  • すべてのビジネス編集を実行すると、編集中のデータ構造が変更されるはずです
  • 手元にあるすべてのデータに基づいて、コントロールの可視性と編集可能性を更新します
  • 検証メッセージやエラー メッセージなど、編集中のオブジェクトからのデータをコントロールに入力します。
于 2008-11-07T21:00:04.203 に答える
2

django がフォームを処理して検証する方法を確認することをお勧めします。フォームはモデルのように処理され、独自のクラスを持っているため、フィールド リスト、検証ルール、および表示ロジックがビュー、コントローラー、およびヘルパー全体に散在することはありません。このような構造を使用すると、非表示/読み取り専用/編集可能なロジックがどこに属しているかが明確になります。

そのような機能はまだ Rails に実装されていないようです。時間を節約するだけでなく、コードをクリーンで構造化した状態に保ちます。検証がコントローラーから分離されているフォームの基本クラスを作成することから始めることができます。

于 2008-11-11T22:48:46.387 に答える
1

適切に機能させるには、アクセス レベルを NONE、VIEW、REQUIRED、EDIT の昇順にする必要があることがわかりました。

REQUIRED はトップ レベルではないことに注意してください。なぜなら、EDIT (populate と de-populate の両方の許可) は REQUIRED (populate のみの許可) よりも大きな権限だからです。

列挙型は次のようになります。

/** NO permissions.
 *     Presentation: "hidden"
 *     Database: "no access"
 */
NONE(0),

/** VIEW permissions.
 *     Presentation: "read-only"
 *     Database: "read access"
 */
VIEW(1),

/** VIEW and POPULATE permissions.
 *     Presentation: "required/highlighted"
 *     Database: "non-null"
 */
REQUIRED(2),

/** VIEW, POPULATE, and DEPOPULATE permissions.
 *     Presentation: "editable"
 *     Database: "nullable"
 */
EDIT(3);

最下層 (データベースの制約) から、アクセスするフィールドのマップを作成します。このマップは、次のレイヤー (ビジネス ルール + ユーザー権限) で更新されます (さらに制限されます)。最後に、最上層 (プレゼンテーション ルール) は、必要に応じてマップをさらに制限することができます。

重要: マップは、その後の更新でアクセスが減少することのみを許可するようにラップする必要があります。アクセスを増加させようとする更新は、エラーを発生させずに無視する必要があります。これは、アクセスがどのように見えるべきかについて投票システムのように機能する必要があるためです。本質的に、すべてのレイヤーが投票すると、各フィールドのアクセスレベルの最低水準点が得られるため、上記のアクセスレベルの後続のレイヤー化は任意の順序で発生する可能性があります。

影響:

1) プレゼンテーション層は、データベース指定の読み取り専用 (VIEW) フィールドのフィールドを非表示にする (NONE にアクセスを設定する) ことができます。

2) ユーザーが少なくとも VIEW アクセス権を持っていないとビジネス ルールで指定されている場合、プレゼンテーション層はフィールドを表示できません。

3) プレゼンテーション レイヤーは、データベースが「必須」(null 不可) のみであると言う場合、フィールドのアクセス権を「編集可能」(null 可) に移動することはできません。

注: "if" ステートメントを必要とせずにアクセス マップを読み取ってフィールドをレンダリングするように、プレゼンテーション レイヤー (カスタム表示タグ) を作成する必要があります。

表示のセットアップに使用される同じアクセス マップは、送信の検証中にも使用できます。すべてのルールが守られていることを確認するために、任意のフォームとそのアクセス マップを読み取る汎用バリデータを作成できます。

(スレッド:フォーム フィールドへのアクセスを制御するためのベスト プラクティスも参照してください)

于 2009-11-16T17:54:33.703 に答える