색인 작업이 막히지 않습니까?

안녕하세요!
이것은 나의 능력 과정이다.

class Ability
  include CanCan::Ability

  def initialize(user)
    can(:manage, :all) { false }
  end
end

나는 여전히/페이지/분류 등에 들어갈 수 있다.나는 그것이 반드시 모든 것을 금지해야 한다고 생각한다.

묘사

class CategoriesController < ApplicationController
  load_and_authorize_resource
  ...
end

class PagesController < ApplicationController
  load_and_authorize_resource
  ...
end

Designshop::Application.routes.draw do
  resources :pages

  scope :except => [:new, :destroy] do
    resources :categories do
      resources :products
    end
  end

  devise_for :users

  root :to => "welcome#index"
end

토론 #1

이 블록은 실제 대상이

토론 #2

호출될 때만 실행됩니다. 전달된 대상에 따라 권한을 더 정의하는 데 사용되기 때문입니다.can? 작업은 전달 대상(전달 클래스만)을 하지 않기 때문에 이 블록을 영원히 호출하지 않습니다.
자세한 내용은 Checking Abilitieswiki 페이지의 "클래스와 함께 검사"부분을 참조하십시오.
내가 짐작컨대 너는 거기에 조건이 있겠지?이 경우 블록 외부에 조건을 배치합니다.
사용자라면관리자?
can:manage,:all
끝맺다
블록은 객체 기반 속성 변경 동작이 필요한 경우에만 사용됩니다.index 네, 이제 알겠어요. 고마워요.그러나 Checking Abilities 페이지에서는 잘 보이지 않았다.
왜 서로 다른 묵인 행위를 실현하지 않습니까?만약 내가 능력 클래스를 완전히 비우면, 나는 어떤 URL도 열 수 없습니다. 이것은 정확합니다.무엇을 해야 하는지(대상이 불러오지 않았거나 검사할 수 없음 등)를 잘 모르면 안전하게 거부할 수 있기 때문에 남성은 이를 알아차리고 일부 규칙을 추가해 복구한다.

토론 #셋

부인하지 않는 것이 좋겠지만'할 수 있다'는 정의를 무시하는 것이 좋다.이전에 선언한 컨텐트는 덮어쓰지 않으며 이후에 선언된 컨텐트가 없으면 거부됩니다.그래서 나는'무시'가 가장 좋은 행위라고 생각한다.

토론 #4

But it was not clear from Checking Abilities page.

응, 나는 이 방면의 문서를 개선하기 위해 노력할 거야.그것으로 하여금 더욱 분명하게 할 건의가 있습니까?

If it is not clear what to do (object not loaded, impossible to check, etc), it would be secure to deny, so a man will notice that and add some rules to fix.

무슨 말인지 모르겠어요.기본 동작은 허가를 주지 않는 한 모든 것을 거부하는 것입니다.

토론 #5

당신은 이 사용자에게 모든 것을 관리할 수 있는 권한을 제공하고 있다고 말합니다.
블록은 객체 속성 기반 능력을 정의하는 데만 사용됩니다.예를 들어 모든 모델에 can :manage, :all 속성이 있고 이 속성을 바탕으로 권한을 변경하기를 원한다고 가정하십시오.
can:manage,:all do | object|
반대, 반대하다보이다
끝맺다
블록을 사용해야 하는 유일한 경우입니다. 블록은 객체를 사용할 수 있을 때만 실행되기 때문입니다.기타 모든 조건은 청크 외부에서 정의해야 합니다.
이 경우, 기록을 가져올 때 사용할 수 있도록 조건을 산열하는 것이 좋습니다.
can:manage,:all,:visible=>true
이게 의미가 있나요?visible

Hmm, I'll try to improve the documentation on this. Any suggestions on making it clearer?

그럼요.나는 약간의 생각이 있지만, 잠시 후에 약간의 글을 써 보려고 시도할 것이다.

The default behavior is to deny everything unless you give permission.

절대 정답!문서를 살펴보겠습니다.

Think of it as asking "can the current user read a project?". The user can read a project, so this returns true.

이것은 어려운 사례이다. 너는 목표가 없다. 너는 정말 허락을 해 줄지 안 해 줄지 모른다.그리고 허락해주기로 했어.질문: 왜요?나의 목적은 이 규칙들을 무시하는 것이다.너는 모르니까 아무것도 하지 마.기본적으로 능력 정의가 끝날 때 이 동작은 거부됩니다.
미안합니다. 저는 영어를 잘 못합니다.

토론 #6

네가 이런 능력을 가지고 있다고 가정해 봐.
can:manage,Category,:visible=>true
이것이 바로 색인 작업

토론 #7

에서 발생할 수 있는 상황이다.
권한 부여!:색인, 분류
@ 범주 = 범주.접근가능(현재 기능)
이것은 결국 보이는 종류만 얻을 수 있는 올바른 행위이다.기본적으로 접근을 거부한다면, 첫 번째 load_and_authorize_resource 호출은 항상 이 작업에 실패할 수 있기 때문에, 보이는 종류를 볼 수 없습니다.
또한, 만약 우리가 새로운 클래스 링크를 가지고 있고, 그들이 클래스를 만들 수 있을 때만 표시하려면 어떻게 해야 합니까
가능하다면?:만들기, 분류
현재, 이것은true로 되돌아갑니다. 왜냐하면, 여기에서 클래스를 만들 수 있는 권한이 있지만, 전제 조건은 특정한 속성과 일치하는 것입니다.우리는 그들이 그것을 만들려고 시도할 때까지 이 속성들을 모른다.만약 authorize! 되돌아온다면, 우리는 이러한 일반적인 검사를 실행할 수 없습니다.
클래스에 대한 검사는 언제든지 검사 실례가 사용할 수 있을 때 후속 검사를 해야 한다.이것은 false를 통해 조건과 일치하는 기록만 얻을 수 있고 속성이 존재할 때accessible_by 작업에서도 얻을 수 있다.
언제든지 능력 모델에 create 호출이 있으면 권한을 부여합니다.블록 또는 해싱 조건은 사용 권한이 적용되는 객체의 범위만 좁힙니다.클래스에 대한 검사가 항상 실패한다면, 이것은 거의 쓸모가 없을 것이다. 왜냐하면, 항상 하나의 실례가 필요하지만, 때로는 실례가 없기 때문이다.
이게 의미가 있나요?can 우선, 이 문제의 주제는 이미 바뀌었다.확실히 Block{user.is admin?}을 사용할 수 없습니다.블록은wiki 페이지에서 언급한 것처럼 데이터베이스 대상을 포함해야 하기 때문이다.
나는 되돌아가는 것이 나쁜 생각이라는 것을 안다.나중에 나는 블록을 실행할 수 없거나 해시를 계산할 수 없는 특정한 상황에서만 CanCan은 이 규칙을 무시하거나 건너뛰어야 한다고 말했다.
네가 말한 바와 같이, 되돌아오기

토론 #8

는 매우 편리할 수 있지만, 이것은 안전한 구멍일 수도 있고, 심지어는 작은 구멍일 수도 있다.나는 너의 목표를 모른다. 어떤 사람들은 엄격한 규칙을 좋아하고, 어떤 사람들은 편안한 환경을 좋아한다.
만약 당신이 이 변화를 실시한다면, 사람들은 색인 조작이 진정으로 허용된다는 것을 명확하게 설명하기 위해 규칙을 추가해야만 할 것이다.그러나 그것은 더욱 정확하고 안전할 것이다.칸칸은 예상한 효과에 도달할 때까지 정확한 규칙을 쓰는 것을 배워야 한다. 칸칸은 '그래, 그가 기록을 보고 싶어한다. 아마도 내가 모든 기록을 볼 수 있도록 허락해야 할 것 같다.' 라고 추측해서는 안 된다.
당신은 사람들이 더 많은 규칙을 늘려 구체화하기가 매우 어렵다고 걱정합니까?false 당신은 구체적인 예를 제공하여 더욱 구체적인 규칙을 추가하면 어떻게 이 문제를 해결할 수 있는지 설명할 수 있습니까?만약 대다수 사람들에게 의미가 있고 안전성을 높이는 해결 방안이 있다면, 나는 그것의 업무 방식을 바꾸고 싶다.
나는 현재의 실현이 안전한 구멍이라고 생각하지 않지만, 더 많은 것은 기능 블록이 어떻게 작동하는지에 대한 오해이다.객체 속성이 있는 권한을 정의하는 데만 사용 가능한 능력 블록이 있는 경우에는 보안 문제를 열어서는 안 됩니다.
적어도 더 좋은 문서가 있을 거야.깨우쳐줘서 고마워요.true 간단한 예를 들면 다음과 같습니다.
can:manage,Project,:public=>true
can: 색인, 항목
당신이 옳다. 만약 한 사람이 문서를 이해하고 엄격하게 준수한다면, 안전에 결함이 있다고 말하는 것은 잘못된 것이다.문서에 경고를 보냈지만, 이것은 매우 보기 드문 기능입니다.
그래, 아직 이 변화를 원하는 사람이 있는지 보자.

토론 #9

네, 토론 라벨을 여기에 붙이겠습니다. 더 많은 분들이 참여해 주시기 바랍니다.

토론 #10

상기 두 규칙의 문제는

토론 #11

조작에 대해 어떤 권한을 설정했는지 잘 모른다는 것입니다.위의 규칙은 색인 작업에서 개인 프로젝트에 접근할 수 있도록 합니다.그럼

토론 #12

전화로 뭘 돌려줘야 하나요?
권한 부여!:색인, 항목
@ 항목 = 항목.접근가능(현재 기능)
이런 상황에서 개인 프로젝트로 되돌아갈 수도 있다. 나는 이것이 네가 원하는 행위가 아니라고 생각한다.:index 내 말은 모든 항목이 색인을 사용할 수 있다는 것이다. 열거할 수 있지만 공공 항목만 표시할 수 있다.그래, 이것은 내가 진정으로 원하는 것이 아닐 수도 있지만, 나는 능력 수업에서 지정한 것을 얻을 것이다.만약 내가 색인 조작을 제한할 필요가 있다면, 나는 내 모델에 accessible_by을 추가해서 내가 무엇을 하는지 똑똑히 알 수 있을 것이다.이것은 더 많은 코드이지만, "그래, 우리가 모든 것을 허락할게."라고 추측하지는 않았다.

토론 #13

If I need to limit index action, I will add a default_scope in my model, and I would have a clear understanding of what I'm doing.

나는 default_scope 여기서 어떻게 일을 하는지 모르겠다.현재 사용자 권한

토론 #14

에 따라 이 동작을 동적으로 실행해야 합니다.이것 또한 권한이 모두 능력류에 분포되어 있는 것이 아니라 각 모델에 분포되어 있다는 것을 의미한다.default_scope 내가 이 글을 끝낸 것은 캔캔 2.0에서 큰 문제가 되지 않기 때문이다.블록을 지정하고 인스턴스를 검사하지 않으면 버전에서 InsufficientAuthorizationCheck 예외가 발생합니다.이렇게 되면 방문하지 않으려는 곳에서는 방문 권한을 부여하기 어렵다.