can:read, 뒤에 can:read, Controller,some 조건이 있습니다.

묘사

안녕하세요.
나는 '모두' 옵션에 문제가 있다.
다음과 같은 기능을 설정할 수 있습니다.

can :read, :all
can :manage, SomeController, :user_id => user.id
can :read, AnotherController, :some_condition => 0..2

그리고 cancan은 단락이 될 수도 있습니다. (적어도 마지막:read를 존중하지 않을 수도 있습니다.)
에서 설명한 디버그 방법 사용https://github.com/ryanb/cancan/wiki/Debugging-Abilitiescancan은 모든 다른 컨트롤러의 기록을 읽을 수 있다고 합니다.
우선, 내가 모든 작품을 읽을 수 있다면.그래서 이것은 마치 모든 것이 탐욕스러운 방식인 것 같다...
이것은 오류입니까? 아니면 제 모든 컨트롤러에 can:read를 지정해야 합니까?
(ruby 1.9.2와 cancan 1.5.1 실행)

토론 #1

이러한 can 호출은 추가된 것이기 때문에 can :read, :all 권한을 부여하면 추가can 호출은 추가 행위만 부여됩니다.전화can는 영원히 행위에 영향을 주지 않는다.이를 위해cannot를 사용할 수 있지만, 이곳의 부정적인 언어 환경은 의미가 없는 것 같다.현재 가장 좋은 해결 방법은 첫 줄에서 서로의 직업을 언급하는 것이다.

can :read, [Article, Comment, Product, ...]

The main reason for this behavior is so you can accomplish "or" conditions easily. For example if you want someone to read either projects he owns or projects which are public you could do this:

can :read, Project, :user_id => user.id
can :read, Project, :public => true

But I see your point here, this does not make as much sense for the :all keyword, it would be better if there were ways to override. I'm marking this for further discussion and will consider changing this in CanCan 2.0.

토론 #2

Hmm, thinking about it some more, the cannot method can be used here like this.

can :read, :all
cannot :read, Project
can :manage, Project, :user_id => user.id

I will still consider changing the behavior of :all in CanCan 2.0, but see if that works for now.

토론 #셋

Ahh I see thanks for the answer.

I totally missed that they are additive, which makes sense for the scenario you describe.

It can as it is be solved using: cannot :read, Controller, ["condition_field > ?", user.upper_bound] do |controller| controller.condition_field > user.upper_bound end

(Needed to dig up: https://github.com/ryanb/cancan/wiki/Defining-Abilities-with-Blocks)

But it would be quite nice, if the :all keyword was just a catch all.

토론 #4

I've been thinking about this, and I think it more has to do with the conditions and not the :all keyword. For example, what if we did this.

can :read, Project
can :read, Project, :user_id => user.id

Here you would assume the second definition would override the first. So I think I need to treat conditions a little special. If a can? check matches a rule with a condition, it should then only match other rules where conditions are applied. This would get the behavior you expect above while still maintaining the additive functionality I mentioned earlier.

Same goes for the new attribute additions in CanCan 2.0. If one doesn't define attributes, but later does, it should override it.

can :update, :projects
can :update, :projects, [:name, :price]

Here you would think the name/price would override the earlier definition since it's more defined. I'll mark this for being added to CanCan 2.0.

토론 #5

Hmm that would make sense. This would mean something like three levels of "specificity" (or two if can :read, :all is meant to be exactly the same as can :read, Project).

I presume that the following would be equivalent:

 can :read, Project, :user_id => user.id
 can :read, Project

다음을 포함합니다.

 can :read, Project
 can :read, Project, :user_id => user.id

이 제안으로 돌아가면, 네가 말한 바와 같이, 블록을 정의할 수 있고, 그 블록을 더욱 구체적인 규칙으로 대체할 수 있다.그러나 이러한 예외 조건을 추가하는 것이 합리적인지 알고 싶습니다.

 can :read, :all, :except => [Project] 

이것은 원시 '문제' 중의 행위를 허용할 것이며, 어떤 경우에는 가능할 수도 있다.:all 현재

토론 #6

의 행위와 일치하기 위해서는 순서에 의존해야 하기 때문에 본 예에서.
can: 읽기, 항목,:user\u id=> 사용자.신분증
can: 읽기, 항목
밑에서부터 첫 번째 패스 규칙에서 멈추기 때문에 최고 조건에 도달하지 못할 것이다.역할이 여러 개인 경우 규칙을 무시할 수 있습니다.
사용자라면역할?:사회자
can: 읽기, 항목,:user\u id=> 사용자.신분증
끝맺다
사용자라면역할?:관리인
can:access,:all
끝맺다
나는 그것의 작업 원리를 다시 고려하고 싶다. 결국 나는 가장 직관적인 행동을 찾고 싶다.
어떤 방식이든 저는 2.0에서 능력 유형을 더 많이 테스트하도록 격려할 것입니다. 권한 수여는 엄격하고 안전해야 하기 때문에 이런 복잡한 규칙은 좋은 테스트를 거쳐야 합니다.cannot 옵션은 현재 조건에 대한 해시와 충돌하기 때문에 추가할 수 없습니다.:except를 사용하여 이 작업을 수행할 수 있습니다.
can:read,:all
:읽기, 항목cannot아 네,
이 평론이 있어서 나는 마침내 규칙이 어떻게 응용되는지 깨달았다.나는 이 규칙들이 어떻게 덧셈이 될 수 있는지 물어보려고 했는데, 네가 말한 바와 같이, 그것은 통과된 첫 번째 권한 수여 규칙만 받아들일 수 있다는 것이 갑자기 생각났다.

토론 #7

+can대cannot에 대해서는 걱정하지 마세요. 이것은 건의일 뿐입니다.:except Ability Precedence 페이지에 이 일을 어떻게 하는지 더 많은 정보가 있습니다.이 페이지를 확장하여 CanCan 2.0 출시 후 여기서 논의한 해시 조건 변경에 대해 설명합니다.