등록 정보 업데이트 후 권한 부여

묘사

현재 update 조작을 통해 모델을 업데이트할 때 데이터베이스에서 모델을 얻어 권한을 부여한다.모델의 속성이 설정되지 않았습니다.업데이트 작업 중에 이 작업을 수행해야 합니다.

@project.update_attributes(params[:project])

The problem is, no authorization happens on the model after the attributes are set. This is inconsistent with the create action where the attributes are set behind the scenes and then the model is authorized.

In the update action, the model has two sets of attributes and therefore should be authorized twice with each set - once when loading the model from the database, and again after setting the attributes. This means one should only do @project.save in the update action since the attributes have already been set. It shouldn't break anything if one still does update_attributes though.

토론 #1

The implementation of this gets a little bit messy because currently there's a clear distinction between load_resource and authorize_resource but this muddies the waters. Would setting the attributes be considered loading the resource? If so, how do we inject authorization into the middle of the loading?

I also can't think of a lot of cases where authorization after setting the attributes is necessary. I'm marking this as "maybe" for now to see if there's any interest in this.

토론 #2

Some applications have to authorize attributes after updating them very often. Think of some multi-tenant application.

There are a task and a task list models. Then on a form user can choose a new list for a given task. Of course each account has its own set of task lists. So after updating a task model, an application should check if the new list id belongs to current account.

I am not sure if it is possible to create general solution for that kind of applications. That solution would be another abstraction layer to load data from db.

Now I am using following pattern:

@model = Model.find params[:id]
@model.attributes = params[:model]
authorize! :update, @model
if @model.save
...

일부 컨트롤러에는 필터 이전에는 전혀 CanCan이 없었습니다.전체 승인 작업은 능력 클래스의 Can 코드 블록에 의해 수행됩니다.
그러나 나는 여전히 정확한 방법이 무엇인지 완전히 믿지 않는다.Rails는 모델 콜백/유효성 검사를 사용하여 속성을 확인합니다.그러나 권한 수여는 사용자 대상이 필요하기 때문에 컨트롤러에 있을 수 있습니다.당신은 어떻게 생각합니까?

토론 #셋

이제 CanCan 로드 코드가 필요합니다. 그러면 authorize! 처리할 대상이 하나 생겼습니다.그러나 코드를 불러오는 것은 일종의 변통 방법으로 볼 수 있다.개인적으로 나는 별도의 기능을 필요로 하지 않는다.ActiveRecord는 괜찮습니다.다른 플러그인도 비슷한 작업을 할 수 있다.
단지 하나의 생각일 뿐이다.아마도 before_filter 다음 authorize! 호출을 위한 작은 환경 (현재 사용자와 조작) 을 설정할 수 있을 것이다.그런 다음 모델 콜백(찾은 후 업데이트하기 전)은 필요한 환경이 있는지 확인하고 정확한 매개 변수를 사용하여 트리거authorize!를 할 수 있습니다.

토론 #4

이것은 모델의 검증 코드에 속하는가, 아니면 Cancan에 속하는가에 대한 좋은 문제이다.물건을 모델의 검증에 넣으면 약간의 후퇴를 초래할 수 있다.한 매니저가 부하의 역할을 관리할 수 있지만 그들에게 관리자의 역할을 분배하는 것은 허용되지 않는다고 상상해 보자.Cancan의 능력으로 쉽게 표현되며, 한 번만 검사하면 실패한다.그리고 모델이 누가 편집되었는지 책임져야 하는 것은 아니다. (비록 당신이 검증기를 가지고 있지만, 그 위에 '만약 나의 매니저가 이렇게 하는 것을 금지한다면, 나는 관리자로 표시되지 않을 것이다.' 라고 쓰여 있다.
나는 위의 그레그가 건의한 모델을 시험해 보고 기분이 어떤지 보겠다.

토론 #5

나는 일단 내가 일반 컨트롤러를 위해 이 문제를 해결하면 상속 자원을 사용해도 더욱 쉽게 해결할 수 있다고 생각한다.현재의 주요 문제는 단독으로 load_resource과 authorize_resource를 사용하면 최종적으로 ControllerResource의 두 개의 단독 실례를 사용할 것이다.
1.5에 skip_* 방법을 추가할 때 나는 이 문제를 해결할 것을 고려했지만 ControllerAdditions에 더 많은 논리를 추가해야 하기 때문에 이런 상황을 피하고 싶다.나는 2.0에서 전체 구역을 다시 쓸 수 있기 때문에 거기서 다시 고려할 것이다.

토론 #6

저는 파티에 늦었습니다. 저는 전체 댓글을 읽는 것에 싫증이 났지만 업데이트에 대한 생각만 말씀드리고 싶습니다. 사람들은 업무에서 업데이트를 하고 권한을 부여받을 수 있습니다. 새로운 속성을 고려하여 없으면 스크롤을 할 수 있습니다.
https://github.com/vhochstein/active_scaffold/issues/92#issue/92/comment/753847

토론 #7

여기는 업무를 사용할 필요가 없습니다. 왜냐하면 데이터베이스에 업데이트된 속성에 대해 권한을 부여할 필요가 없기 때문입니다.우리는 속성 설정이 끝난 후에 다시 authorize! 방법을 통해 실례를 운행하기만 하면 된다.
CanCan은 데이터베이스에 특정 컨텐트를 제출하지 않아야 하며 메모리의 인스턴스만 처리해야 합니다.일부 내용을 데이터베이스에 저장하려면 컨트롤러의 사용자가 실행해야 합니다.
이 책의 가장 큰 문제는 라이선스와 로드를 분리하기는 어렵지만, 캔캔 2.0에서는 이를 걱정하지 않기 때문에 이 책에서'연구'해시태그를 삭제할 것이다.거기에 쉽게 추가할 수 있을 거예요.