접근 능력 클래스의 삽입 자원

안녕하세요.
"sub articles"자원을 끼워 넣은 "article"자원을 가정해 봅시다.
우리는 하위 약관 클래스에서 다음과 같이 정의합니다.

load_and_authorize_resource :nested => :article

Now let's imagine we want to allow users to manage SubArticles only for Articles that they own.

we would like to put something like this in our ability class :

can? :manage, SubArticle do
  @article.created_by == user
end

however we do not have an @article variable, we are in the Ability class scope and not in the SubArticles controller's scope.

It would be really nice if the can? method in the Ability class supported resources nesting as tree (hash) of models like so :

can? :manage, {Article => SubArticle} do |article, sub_article|
  article.created_by == user
end

Thanks again for this great library :)

토론 #1

Hi! May be this will work it out:

can? :manage, SubArticle do |sub_article|
  sub_article && sub_article.article.created_by == user
end

다음 비디오를 보십시오.http://railscasts.com/episodes/192-authorization-with-cancan

묘사

안녕!
당신의 건의에 감사하지만, 나는 이 해결 방안이 '편집', '업데이트', '소각' 작업에만 적용되는 것에 매우 놀랐다.
네가 건의한 해결 방안은 기록이 있어야만 작용할 수 있다.'만들기', '새로 만들기', '인덱스' 를 호출할 때 기록이 없기 때문에 사용자의 역할이나 IP 요청, 다른 어떤 방식으로든 이 능력을 확인할 수 있습니다.
railscast에서 이것이 효과가 있는 이유는 논평된 글이 논평을 만들거나 열거하는 기준이 아니기 때문이다.

토론 #2

오늘 저는 이 해결 방안을 이용하여 지역사회에서 구성원 신분을 만들었습니다(사용자는 자신만 지역사회에 추가할 수 있습니다).나는 네가 틀렸다고 생각한다.

토론 #셋

와 authorize resource:nested가'new'와'create'를 정확하게 처리한 것 같아서 새 기록과 끼워 넣은 자원 간의 연결을 만들어서sub article가nil과sub article가 아니도록 했습니다.article에서article 대상을 정확하게 제시했습니다.그래서 새로운 방법과 창설 방법에 대한 나의 견해가 틀렸습니다. 죄송합니다.
그러나 색인 방법에 대해 나는 여전히 운이 좋지 않다(sub 문장은 0이기 때문에 나는 문장을 얻을 수 없다).그거 알아요?

토론 #4

사용자는 무엇을 사용할 수 없습니까?:)설명

토론 #5

은 사용자가 가지고 있지 않은 글과 대응하는 하위 글을 열거하는 것을 막으려고 합니다.
Uri의 경우:
사용자 Alice가 제1조를 가지고 있다
사용자 Bob 보유 제 2 조
앨리스가 출입이 금지됐으면 좋겠어요.http://host/articles/2/sub_articles어이, 알았어.이 컨트롤러에서 Before 필터를 사용할 수 있습니까?

토론 #6

before 필터에서 이러한 테스트를 진행하면 cancan의 모든 목적을 좌절시킬 수 있습니다. 즉, 하나의 파일에서 당신의 모든 능력을 정의하는 것입니다.
아닌가?네 말이 맞다.간단한 리소스가 있으면 CanCan은 매우 편리합니다.라이언에게 물어보거나 캔캔의 출처를 찾아보면서 가장 좋은 방법을 찾아보세요.
행운을 빕니다!

토론 #7

비슷한 일을 시도하고 있습니다.센서는 사용자에 속하고 로그 파일은 센서에 속하며 로그 파일 경로는 특정 사용자가 가지고 있는 센서가 만든 로그 파일만 보여 주기를 바랍니다.
이것이 바로 심층 플러그인 로드 자원과 권한 수여 자원이 해결해야 할 문제입니까?만약 그렇다면, 하나의 예 능력이 규칙적으로 유익할 것이다.

토론 #8

컨트롤러 논리를 능력 클래스로 이동하려고 시도하고 있다고 생각합니다.디렉터 # 인덱스에서 사용자 센서가 작성한 로그를 선택해야 합니다.모든 사용자가 페이지 컨트롤러 # 인덱스를 열 수 있지만 각 사용자는 서로 다른 로그 목록을 볼 수 있습니다.

토론 #9

cancan의 목적은 컨트롤러 논리를 능력 클래스로 옮기는 것이지만 권한 수여 논리에만 한정된다.
자원이 끼워져 있다는 것을 잊지 마라!
이것은 로그 파일 인덱스가 '모든 센서' 이고 다음과 같은 경로가 있기를 희망한다는 것을 의미한다
http://host/sensors/:sensor_id/log_files
LogFilesctroller에서 색인 작업에 액세스합니다.
만약 사용자가 센서를 가지고 있지 않다면, 우리는 이 색인 작업 중의 데이터만 필터하고 싶지 않다. 우리는 사용자가 금지되거나 방향을 바꾸기를 원하고, 이러한 논리는 능력류에 명확하게 들어가야 한다.

토론 #10

동의

토론 #11

내가 알기로는 이게 너한테 괜찮겠니?

# in SubArticlesController
load_and_authorize_resource :nested => :article
before_filter :authorize_article
private
def authorize_article
  authorize! :read, @article
end

Basically, this will check that the user has :read permission on the @article resource before accessing the subarticles. I will consider building this into the authorize_resource method if it solves the problem.

토론 #15

Yes, this works very well, thanks a lot ! But there's still a bit of authorization logic in the controller itself when you call the authorize! method. If you move this to the authorize_resource method ( I think it would be a great addition), it would be really nice to have the flexibility to specify the action that is authorized on the parent resource (in your example you use :read).

I will definitely use your solution for now, it's much cleaner than what i've come up with :) thanks !

토론 #16

Ryanb, did you build this in? If so how do we use it? I'm struggling with this at the moment on a very time sensitive project (not your fault I know but any help is very much appreciated!). Thank you very much. -Jon

토론 #17

@ryanb: This could work, but only in some scenarios. Here :read permission for @article is enough. But I have the case where user can manage project's memberships, and he's required to be manager of the project.

I think better would be to just pass parent resource to can block as the last argument:

can :index, Membership do |membership, project|
  user.managable_projects.include?(project || membership.project)
end

나는 이렇게 하면 더욱 유연할 것이라고 생각한다.

토론 #12

참고로 Junaid fork에서 구현되었습니다.
http://github.com/junaid/cancan/commit/fdb7510737e925752a7f60cbf0f9c5f583a4a734
이 제출은 다른 내용을 추가했지만, can 블록에 부모 자원을 추가하는 것을 볼 수 있습니다.내가 보기에 이것은 가야 할 길이다.

토론 #13

제83기 별도.
나는 여전히 이 일을 조사하고 있으며, 좋은 해결 방안을 통합하려고 시도할 것이다.

토론 #14

CanCan 1.3의 중첩 동작이 크게 변경되므로 이 기능을 해제합니다.나는 몇 가지 문서를 추가했고 Nested Resourceswiki 페이지 밑에 있는 문제를 해결하려고 시도했다.
일단 Can Can 1.3이 발표되면, 그것이 당신의 문제를 해결할 수 있는지 시험해 보세요.만약 없다면, 왜 그것이 그것을 해결할 수 없는지 설명하는 단독 문제를 발표하십시오.

토론 #18

대박!감사합니다!