5

こんにちは、私は rolify を使用していますが、実際にはその可能性を十分に活用していないことに気付きました。

現在、私はコントローラーでユーザーを再ルーティングするなどのことを行っていますcurrent_user.has_role? :whatever_role、およびユーザーが他の役割を持っている場合はユーザーを許可します...

誰かが roify について stackoverflow で質問をしましたが、それに答えようとしたときに、自分のやり方が間違っていることに気付きました。

さて、ここから私の混乱が始まります...

user ||= User.new # guest user (not logged in)
if user.has_role? :consumer
  can :manage, Review
else
  can :read, Review
end

ここで、コンシューマー ロールをユーザーに追加するとします。

x=User.last
x.add_role :consumer
# => #<Role id: 10, name: "consumer", resource_id: nil, resource_type: nil, created_at: "2013-04-18 23:00:46", updated_at: "2013-04-18 23:00:46">

ロールが作成されます。これを確認するには、次のようにします。

x.has_role? :consumer
=> true

これで、レビューの管理機能が得られると思います...

x.has_role? :consumer, Review
=> true

他のモデルではありません...ここで私は製品を試します

x.has_role? :consumer, Product
=> true

さらに、「リソースロールのクエリ」を見て、レビューのために適用されたロールをクエリしようとすると、適用されたロールが見つかりません。

Review.first.applied_roles
=> []

誰かロリファイを説明してくれませんか。ありがとう

4

1 に答える 1

38

私の答えは、このreddit投稿からの質問を飾ります:

認証とは、User自分が誰であるかを証明することです。

認証とは、Userユーザーが ID を確立した後で、特定のアクション (読み取りまたは書き込み) を実行できることを確立することです。

ロールは、ユーザー間での承認の一般的なパターンにすぎません。これUserはそのまま承認することも、代わりにこのように承認することもUserできます。

ここで欠けている要素はPermissionsRoleです: 確立されたコントローラー アクションと何らかのコントローラー アクションとの間の関係です。

Rolesが実行できるアクションについて、それ自体は約束しませんUser。そして覚えておいてください-承認はすべてアクションに関するものです。あなたが扱っているRolesものの種類を一般化します。これらは、 の巨大な洗濯物のリストをUserすべて照会する必要がないようにするために存在します。彼らは宣言します：これは！もちろん、彼らはそれをしなければなりません！UserPermissionsUserRolePermission

には多くの種類がありPermissionます。それらを編集できるように十分に承認 したい場合は、それらをデータベースに保存できます。または、十分に静的な場合は、Ruby コードで事前に管理できます。UsersRolesUser's RolesPermissions

  • 構成可能なRolesandが必要な場合Permissions、つまり、契約の完了時に誰かに引き渡すクライアント アプリケーションの場合、独自のカスタム モデルでaUser :has_many Rolesと aを実装し、 my にフックを追加し、それにメソッドを記述します。これらの期待に対処する方法、またはアクセスしてはならないものに公開したいものへの URL を手動で入力することを主張する人々のために 403 ページをレンダリングする方法を知っている.Role :has_many Permissionsbefore_filter :authorizeApplicationControllerauthorizeactions

  • configurable だけが必要な場合は、 Ryan Bates の CanCan gemRolesを使用します。

  • Rolesとを事前に定義したい場合は、 RolifyをNathan Long の AuthorityPermissionsと組み合わせて使用​​し、オーソライザー クラスを介してクラスベースの非常に柔軟なものを取得します。Permissions

RolesとはどちらもPermissions、ユースケースに応じて、クラスベースまたはインスタンスベースのいずれかになります。rolifyたとえば、発見したばかりの能力を使用して、特定のインスタンスベースの状況でUsersのみ機能することを決定できます。Roleまたは、アクションを実行しようとしているオブジェクトが特定のタイプであるRoles場合にのみ、アクションUserを実行できる可能性があります。

これらの順列を調べるには、ブログ アプリケーションを想定して、次の式に従います。

a User/an Role class/instancecan actiona/an/all/any/that ( class/instance) Permission:

  • RoleクラスとPermissionクラス:

    何でもできる人Userです。AdmindeletePost

  • RoleクラスとPermissionインスタンス:

    すべてのことUserがAdminできる人editPosts that they approved to be published

    公開された投稿にIDapproved_byを指すフィールドがあれば、これはより簡単になります。User(この種の状況では、ステート マシンの gemを使用します。

  • RoleインスタンスとPermissionクラス:

    User誰でもan Author of a Postできる_commentPost

    Rolifyこの種の状況はまれであることに注意してください。そのため、この状況を処理するために上記で言及した宝石はありませんAuthority。または、この決定をクライアントに渡す必要がある場合は、独自のカスタム ソリューションを使用します。

  • RoleインスタンスとPermissionインスタンス:

    User誰がそれをすることがan Author of a Postできます。editPost

TL;DR:

  • Rolify役割のためだけです: grouping Usersby Permission: コントローラー アクションへのアクセス。どのように管理するかはまだ決めていませんPermissions。

これが、認証と承認Rolifyの壮大なスキームにおける の位置付けを理解するのに役立つことを願っています!

于 2013-04-19T03:35:07.260 に答える