disable risk blocks () 위험성이 있는 기본 블록 동작을 비활성화합니다.

묘사

이 간단한 능력 정의를 생각해 보자.

class Ability < ActiveRecord::Base
  include CanCan::Ability
  def initialize(user)
    can :manage, Group do |group|
      user.admin?
    end
  end 
end

이 패치가 없으면, 비 관리자가 그룹을 만들 수 있다는 것을 발견하면 깜짝 놀랄 수도 있습니다.이것은 캔캔이 권한을 부여받은 클래스 (대상이 없음) 에서 항상true로 되돌아갈 수 있도록 블록을 정의하기 때문입니다.금지할 방법이 없는 것 같습니다. 블록 논리를 효과적으로 사용하지 않는 상황에서 그룹에 대해 새로운 작업을 진행합니다.
이 패치를 사용하면 disable\u risk\u blocks () 를 호출하여 블록이 인증 클래스에서 true 대신 false로 되돌아갈 수 있습니다.

class Ability < ActiveRecord::Base
  include CanCan::Ability
  def initialize(user)
    disable_risky_blocks
    can :manage, Group do |group|
      user.admin?
    end
  end 
end

현재 관리자가 아닌 사용자는 그룹을 생성할 수 없습니다.허용하려면 다음을 추가하십시오.

  can :new, Group

나에게 쓸모가 있는 것 같다.

토론 #1

비키상:
https://github.com/ryanb/cancan/wiki/Defining-Abilities-with-Blocks

토론 #2

특별히 가리키고 싶은 게 있나요?

토론 #셋

아, 죄송합니다. "객체 속성에만 적용"아래의 내용을 읽으신다면.고맙습니다.나는 네가 수업을 통과할 때 이 구역은 불려오지 않을 것이라는 것을 안다.반대로 트루는 자동으로 되돌아와 불쾌한 기쁨을 초래할 수 있다.이 인출 요청은 기본값을false로 변경합니다. (블랙리스트가 아닌 화이트리스트 방법)

토론 #4

기본값은 직접 변경하지 않고 변경할 수 있습니다.

토론 #5

@emiltin 이pull 요청에 이 용례의 규범을 포함할 수 있습니까?왜 블록의 행동을 바꾸지 않고 항상false로 되돌아갑니까?

토론 #6

문제는 테마가 클래스일 때 블록을 호출하지 않는다는 것이다.반대로true는 자동으로 되돌아옵니다.

토론 #7

@emiltin: 야, 너 이 행동에 규범을 좀 더 줄 수 있어?그것은 pull 요청을 합병의 좋은 후보로 만들었다.고맙습니다.

토론 #8

네, 규격을 추가했으니 오늘 늦게 출시할 수 있기를 바랍니다.
그나저나 루비 1.9에서 많은 규범이 실패한 것 같은데?

토론 #9

@emiltin I와 @ryanb는 1.6.7이 여전히 1.8.7에서 개발되고 있음을 확인했다.

토론 #10

여기는 규범입니다. 저는 upstream/master

토론 #11

에 지점의 기초를 다시 설정했습니다. 단일 제출

토론 #12

@emiltin을 좋아하는지 알려 드리겠습니다. CanCan 2.0의 실현을 확인한 후에 CanCan은 오류(정보가 부족하거나 유사한 것)를 던지고 클라이언트가 합리적인 방식으로 처리하는 것이 가장 좋다고 생각합니다.권한이 부여되지 않은 요청과 유사합니다.
규격을 써 달라고 해서 죄송합니다.이렇게 하는 것이 더 의미가 있다.당신은 어떻게 생각합니까?당신의 의견을 제시해 주세요.고맙습니다.

토론 #13

합리적(안전)위약은 틀림없다고 생각합니다.
나도 무슨 정보를 잃어버렸는지 분간할 수 없다.클래스를 can ()

토론 #14

에 전달하는 것을 허용한다면, 합리적인 (안전한) 기본값을 사용하는 것이 틀림없다고 생각합니다.
나도 무슨 정보를 잃어버렸는지 분간할 수 없다.클래스를 can () 에 전달하는 것을 허용한다면, 사용자가 무엇을 전달하길 원하십니까?

토론 #15

@emiltin: 제가 잘못된 소식을 말했을 때 제 뜻은'정보 부족'이 아닙니다.그러나 이것은 사용자에게 "헤이, 네가 이 대상으로 어떤 일을 할 수 있는지 알려줄 실례가 필요해."라고 wiki가 이미 말했다.불쾌한 사고로부터 사람들을 보호하기 위해 명확한 실수를 던져도 아무런 사고도 없을 것이다.
당신은 어떻게 생각합니까?

토론 #16

그러나 실례를 전달해야 한다면 사용자가 어떤 물건을 만들거나 인덱스할 수 있는지 어떻게 검사할 수 있습니까?이것은 나에게 아무런 의미가 없다.

토론 #17

실례를 통과할 필요가 없다.좋아, 이 문제를 해결할 더 좋은 방법이 있어.
좀 도와주시겠어요?당신이 쓴 위험 블록 코드를 어디서 사용하는지 우리에게 예를 보여 주십시오.이것은 우리를 더욱 잘 설명할 수 있을 것이다.고맙습니다.
2012년 6월 25일 08:23, 에밀[email protected]쓰기:

but how can you ever check if a user is allowed to create or index a Something, if you're required to pass an instance? this doesn't make sense to me.

---

Reply to this email directly or view it on GitHub: https://github.com/ryanb/cancan/pull/622#issuecomment-6541074

토론 #18

:

def create
  authorize! :create, BlogEntry
  #create new blog entry
end

패치 없음, 권한 부여!항상 진가를 되돌려줍니다.고맙습니다.나는 네가 이렇게 해서는 안 된다고 추측한다.
can: 사용자, 그룹 만들기.관리자?
아마도 너는 복잡한 상황을 검사해야 할 것이다.오해하지 마세요.나는 이 기능을 완전히 지지한다. 그것은 불쾌한 의외의 사고를 없앨 수 있지만, 나는 단지 더 좋은 실현을 시도하고 싶을 뿐이다.

토론 #19

네, 사용자마다 다른 그룹에 접근할 수 있기 때문에 막아야 합니다.이 예는 단지 좀 간략화했을 뿐이다.

토론 #20

나는 이것이 CanCan 1의 문제라는 것을 깨달았다.그러나 적절한 복구는 결코 간단하지 않다. 이것이 CanCan 2의 작업 방식을 바꾸는 주요 동기이다.나는 1년 안에 이 문제를 해결할 생각은 없다.2.0 버전에 중점을 두고 싶어요.

토론 #21

나는 이 패치가 매우 간단하고 눈에 띄지 않는다는 것을 스스로 발견했다.하지만 좋아, 내가 그것을 여기에 놓고 너희들이 2.0에 관심을 가지도록 할게.