私は、BlazeDSとともに、UI側でFlex 3を使用し、サービスレイヤーでjava@を使用してコーディングされたアプリケーションを持っています。次に、データベースで定義されている役割に基づいて、システムにアクセスするユーザーを承認する必要があります。たとえば、役割ゲストを持つユーザーは、UIの[管理]タブにアクセスできないようにする必要があります。ダッシュボードに表示されるデータの表示以外の操作。また、ここで注意すべき点は、UIからスーパーユーザーが役割を動的に作成できることです。
ロールベースの認証と承認を実行する方法を説明するこのリンクに出くわしました
このアプローチでは、service-config.xmlでロールを定義する必要がありますが、ロールが事前定義されていないため、これを使用することはできません。
誰かが同じような状況に遭遇したことがありますか。どんなポインタも大いに役立ちます。
はい、私もservice-configのアイデアが好きではありません、あなたを責めないでください。
フレックス側に関しては、心配する必要があるのは、もちろんロールやユーザーではなく、権限を定義することだけです。
適切な形式の役割ベースのセキュリティには、ユーザー、役割、および権限の定義が含まれます。あなたはおそらくこれを知っていますが、とにかく質問でそれを大声で言うのは良いことです。
したがって、アプリケーションでは、特定のアクセス許可（セキュリティに依存するアプリの一部）を定義します。表示/非表示/実行可能または実行不可など。通常、これを行う方法は文字列定数を使用することです。したがって、注文管理の状況では、、、、、がありCanCreateOrderます。CanViewOrderCanCancelOrderCanFlagOrder
サーバー側では、役割はこれらの権限に関連付けられます。まあ言ってみれば：
したがって、サーバー側では、管理者であるユーザーAが、割り当てられたロールに関連付けられたすべての権限のリストを取得するため、サーバーは次のような文字列を送り返します。CanCreateOrder,CanViewOrder,CanCancelOrder,CanFlagOrder
アプリケーション内で、ユーザーが認証されてそのリストを取得すると、そのリストはどこかの静的グローバル変数に格納されます（または、配列などに.split（）されます）。
次に、個々のアイテムの可視性またはアクセスをチェックするときに、その配列または値の文字列をチェックするだけです。
これにより、定義する項目、最も重要なのは、基本的にハードコーディングしているアクセス許可が、それらが存在する関数型コードに固有であるため、多くの柔軟性が提供されます。したがって、それらを調整する必要はありません。
したがって、カスタマーサービス担当者が後で注文をキャンセルできるようにする場合は、その権限をその役割に関連付けるだけです。終わり。コードを変更する必要はありません。これは、権限がユーザーではなく、役割ではなく、その機能に関連付けられているだけだからです。
私はこれを多くのアプリケーションで行ってきました。その堅実な設計です。他のキーに関連付けられたアクセス許可が必要な場合、それは少し異なる話ですが、これは関係なく良い出発点です。
わかる？
**当然、セキュリティ交換を暗号化してSSL経由で送信し、そのトランザクションを保護することは議論の範囲外です;）