기본 제한 사항

묘사

Lockdown 프로젝트에 대해 저는 몇 가지 감상을 했습니다. 저는 칸칸에 이런 것들이 부족하다고 생각합니다.
1. 기본적으로 모든 것이 잠겨 있습니다.
2. RESTful 컨트롤러에만 해당되지 않습니다.
Ensure Authorization로 이를 모방하고 Non RESTful Controllers에는 캔캔을 사용할 수 있다.나는 이런 행위가 더욱 간단하고 직관적이기를 바란다.
권한을 부여할 수 있는 컨트롤러 종류가 있다면?이것은 보통 ApplicationController에서 완성되기 때문에 모든 내용이 제한된다.

class ApplicationController < ActionController::Base
  enable_authorization
end

This would add a before_filter to every action which checks the permission on Ability. The default behavior would simply pass in the controller action name as the verb and the controller name as the noun.

can :create, :projects

This makes Non RESTful controllers just as easy to limit. For example, if there's a HomeController#index action we could do.

can :index, :home

The action aliases are still set up so one can use :read or :manage instead of :index there.

The problem is how will this fit in with handling conditions based on model attributes. Also, because this changes the focus to controller actions it makes setting permissions on individual attributes (see #154) less obvious.

Just throwing this idea out there, let me know what you think!

토론 #1

I will be moving forward with what's mentioned in this issue for the 2.0 release.

I will also be changing :manage to :access because it's more generic and fits other non restful controllers.

can :access, :home # can access any action on home controller

Checking on model instances will match based on the pluralized class name.

can :read, :projects, :discontinued => false
can? :read, Project.new(:discontinued => false) # will return true
can? :read, :projects # will return true like normal

Using a class directly will be deprecated. For cases where the subject name can't be inferred there will be support for subject aliases which work much like action aliases. There will be the ability to pass a class name and alias it to a subject name.

alias_subject User, :to => :authors
can :read, :authors
can? :read, User.new # returns true

Since authorization will be enabled by default in all controllers. The load_and_authorize_resource call will be deprecated and only load_resource will be needed. One can call skip_authorization on any controller where they don't want authorization to take place. This works for restful and non restful controllers.

load_resource
skip_authorization

Setting permissions for individual attributes will also be supported as mentioned in issue #154.

can :update, :projects, [:name, :priority]
can? :update, @project, :name # returns true

This removes the need for attr_accessible in models since each attribute will be checked automatically with authorization if you're using load_resource.

This also makes it easier to add conditions for parent resources when nesting is involved. The association can be treated as an attribute:

can :access, :projects, :categories

These are all some ideas on where I see CanCan 2.0 going. What do you think?

토론 #2

is it posible to add a method that prints the resulting permissions for a given resource? it would be so helpful during development.

토론 #셋

Good idea. I hope to improve debugging in 2.0 including a way to enable logging which will state all the permissions it goes through, etc.

토론 #4

How is the attributes default to be handled?

 can :update, :projects # allow to all attributes
 can :update, :projects, [:name, :priority] # allow only these two attributes

나는 :only와:except 어의학이 이곳에서 매우 좋은 후보자라고 생각한다

 can :read, :user, :only => [:email]

토론 #5

이외에 모든 컨트롤러의 기본 사용 권한 부여는 종료를 선택해야 합니다.

토론 #6

@clyfe, 건의해 주셔서 감사합니다.나는 아직 세 번째 매개 변수의 모든 가능성을 고려하지 않았다.나는 약간의 실험을 해야 한다.옵션의 only/except 산열을 허용하는 문제는 조건 산열의 사용과 충돌하는 것입니다.
나는 우리가 cannot전화를 더 많이 이용할 수 있다고 생각한다.하나 이상의 속성을 제외한 모든 속성을 실행하려면 이 작업을 수행합니다.
can: 업데이트,: 제품 # 모든 속성 허용
없음:업데이트,:제품,:가격
세 번째 매개 변수에 대한 옵션을 추가하는 것도 고려할 것입니다. 이 옵션은 항상 필요합니다.이렇게 되면 시종일관 속성을 명확히 하고 :all를 사용하여 모든 속성을 표시해야 한다.
필요 속성
can:업데이트,:제품,:전부
만약 누군가가 그것을 대체한다면 attr_accessible, 나는 이것이 그들이 어느 곳에서도 그것을 잊지 않도록 하는 좋은 해결 방안이라고 생각한다.

토론 #7

당신의 두 번째 제안에 대해 enable_authorization 방법은 :if와 :unless 옵션을 받아들여 동적으로 사용하지 않습니다.나는 호출할 수 있는 skip_authorization 방법을 추가하는 것을 고려했지만, load_and_authorize_resource 에서 권한을 부여하고 불러오는 것을 분리하는 것은 복잡해질 것이다.Can Can 1은 이를 시도했지만, 나는 그것이 잘했다고 생각하지 않는다.
컨트롤러에서 권한을 '건너뛰기' 하려면, 능력 클래스에서 접근을 허용하는 것도 마찬가지로 쉽기 때문에, 이것이 꼭 필요한지 모르겠습니다.이것은 내가 그것을 테스트할 수 있을 때까지 기다릴 수밖에 없을 것이다.

토론 #8

내가 여기서 언급한 대부분의 내용은 현재2.0 branch에서 실현되었다.이거 닫아.만약 네가 구체적인 문제를 발견한다면, 새로운 길을 열어라.