現在、ユーザーが仕事を作成して応募できるアプリを作成しています。ただし、私はレールにかなり慣れていないため、ユーザーが正しいパスを知っている場合、次のようなかなり重要なセキュリティ機能に直面しています。
localhost:3000/users/user_id/apps
その後、彼らは、任意のユーザーが任意のジョブに対して作成した任意のアプリケーションを見ることができます!
before_filtercurrent_user.id が各ジョブの job テーブルにある user_id と一致するか、applications テーブルにある user_id と一致するかを確認するために a を使用する必要があると確信しています。
ただし、これを構造化する方法やフィルターを適用する場所が本当にわかりません。たとえば、アプリケーションコントローラーでフィルターを作成し、skip_before_filter必要に応じてインスタンスを適用する方がよいでしょう。
このコードの作成とその配置場所について人々が提供できるヘルプは大歓迎です! ありがとう ：）
cancan などの認証ソリューションを検討する前に、簡単な方法は、次のことを避けることです。
App.find params[:id]
アプリはユーザーに関連付けられており、 current_user セットアップを実行できるため、
app = current_user.apps.find params[:id]
検索するパラメーターに関係なく、ユーザーに関連付けられたアプリのみを検索します。
cancan が真価を発揮するのは、誰がどのシステムを実行できるか、より複雑なシステムが必要な場合です。たとえば、ユーザーは自分が作成したジョブを編集できますが、別の一連のジョブを表示できます (編集はできません)。
例えば
can :manage, Project, :user.id => user.id
can :read, Project, :department => user.department
これにより、ユーザーは自分のプロジェクトへのフル アクセスと、自分の部門のプロジェクトへの読み取りアクセスを許可されます。
cancan のもう 1 つの点は、before_filters やマクロをコントローラーの周りに散らばらせるのではなく、1 か所でルールを宣言するので、通常は何が起こっているのかを簡単に確認できることです。cancan wiki と railscast にも多くの情報があります。
あなたは正しいですがbefore_filter、それは解決策かもしれませんが、最先端の解決策ではありません。そのためのレールキャストがあります、...
http://railscasts.com/episodes/192-authorization-with-cancan/
cancanを使用しているが考案していない場合current_userは、現在ログインしているユーザーのUserオブジェクトを返すヘルパーを作成する必要があります...