1

他のいくつかのアプリに認証システムを提供する RESTful Web アプリを設計しています。他のアプリは、HTTP を介してこのアプリにクエリを実行し、認証されたユーザーを記述する XML を取得します。

認証アプリは、どのユーザーがどのアプリケーションで何を行うことが許可されているかを追跡する必要があります。

DBスキーマを作成しています。以下は私の最初のデザインです。(各テーブルに列があると仮定しidます。)

applications  # The various client apps that will query this auth system.
------------
name

users         # Table simplified for discussion
-----
username
password
email

roles
-----
name
application_id

roles_users
-----------
role_id
user_id

アイデアは、誰かが「Equipment Inventory」アプリで管理機能を実行しようとしたとします。したがって、「Equipment Inventory」は、認証システムに対して「ユーザー名 xxx とパスワード yyy を持つユーザーを取得する」と言います。次に、(ActiveResource を介して) 返されたUserオブジェクトを調べ、そのroles配列に、「Equipment Inventory」という名前のオブジェクトにRole属する「ADMIN」という名前の が含まれているかどうかを確認します。Application

または、テーブルを削除して、" "、" "、" " などapplications、より多くの役割を持たせた方がよい場合もあります。equipment_inventory_adminequipment_inventory_readonlyjob_tracker_admin

Application エンティティを正規化することと、テーブル構造を単純化することのどちらがより重要でしょうか? おそらく、すべての入力の後、私は自分の質問に答えたばかりですが、コメントや提案は大歓迎です.

4

3 に答える 3

1

認証と承認を確実に分離します。（あなたがそうしているように見えます;「ユーザー」テーブルは認証に分類され、残り+ user.idは認証に分類されます）

パスワード: 平文で保存していませんよね? MD5 ハッシュ (+攻撃を防ぐためのソルト) を保存すると、より安全になります。

ケルベロスは可能性がありますか？(おそらく、トランスポート層として HTTP を介して動作するように適合させることができます)

于 2009-01-29T23:04:51.160 に答える
1

スキーマは正常に見えます, あなたは送信します

<login><username>abc</username><password>xyz</password><app>51</app></login>

そしてあなたは戻ってきます

<auth> <user> <username>abc</a> <lastlogin>123456464</lastlogin> </user> <app> <name>Equipment Inventory</name> <version>3.1.5e</version> </app> <roles> <role>admin</role> <role>manager</role> <role>dataentry</role> </roles> </auth>

また

<auth><error type="1"></auth>

于 2009-01-29T22:39:55.220 に答える
0

個人的には、正規化の側で誤りがちです。少なくとも私の経験では、何らかの追加モジュールが追加されます。アプリケーションに行を追加し、必要に応じて新しいテーブルを追加してから、既存のスキーマを編集し、関連するすべてのデータ アクセス コードを更新する方がはるかに簡単です。

編集：もう一度見てみると、ロールテーブルとロールユーザーテーブルをマージできます。アプリケーションごとにロールと、ユーザーがロールにアクセスする方法を定義する 1 つの場所である可能性があります。

于 2009-01-29T20:59:07.390 に答える