2011-04-27 4 views
1

나는 로그인 한 사용자를 기반으로 두 가지 "컨텍스트"에서 실행되는 컨트롤러를 가지고 있습니다 (기본적으로 사용자는 자신의 계정에서 CRUD 작업을 수행 할 수 있으며 관리자는 모든 사용자 계정을 CRUD 할 수 있습니다. 동작은 컨텍스트간에 동일하지만 사용 권한은 다릅니다.생산 모드의 append_before_filter

:

def ensure_logged_in 
    if user_context? 
    self.class.append_before_filter :authorize_user 
    else 
    self.class.append_before_filter :authorize_admin 
    end 
end 

또한, ensure_logged_in이 특정 행동에 호출이를 용이하게하기 위해

, 나는 상황을 확인하고 필터 전에 올바른 상황에 특정 권한을 추가 필터 전에 쓴

before_filter :ensure_logged_in, :only => [:show, :edit, :update] 

이 코드는 개발 모드에서 완벽하게 작동하지만 일단 코드가 생성되면 이상한 동작이 발생하기 시작합니다 (예 : 사용자가 로그인 할 필요가없는 작업을 위해 로그인하라는 메시지가 나타납니다. 컨트롤러에서보기 동작을 몇 개 열어 놓음).

내 생각에 개발은 각 페이지가 충돌 한 클래스를 다시로드하기 때문에 append_before_filter 호출은 페이지 히트에만 적용되지만 프로덕션 캐시 클래스는 append_before_filter을 호출하면 후속 컨트롤러 사용을 위해 추가됩니다. 이것은 유효한 가정입니까? 그렇다면 대신 무엇을 할 수 있습니까?

답변

2

내 생각 엔 개발 클래스 각 페이지 히트를 다시로드 때문에 append_before_filter 호출이 해당 페이지 히트에 적용하지만, 생산 캐시 클래스 때문에, append_before_filter를 호출하면 컨트롤러의 후속 용도를 추가한다는 것입니다. 이것은 유효한 가정입니까? 그렇다면 대신 무엇을 할 수 있습니까?

귀하의 진술은 정확합니다. 프로덕션에서는 클래스가 지속 적이기 때문에 클래스의 필터 체인을 변경할 수 없습니다. 따라서 필터 체인을 변경하면 해당 컨트롤러 클래스가 처리 한 모든 요청이 그 시점부터 적용됩니다. 난 그냥 이런 user_context? 뭔가를 기반으로 다른 것들 중 하나를 호출 필터 방법, 이전에 정상을 사용 : 그 반환을위한

before_filter :ensure_logged_in, :only => [:show, :edit, :update] 

def ensure_logged_in 
    if user_context? 
    return authorize_user 
    else 
    return authorize_admin 
    end 
end 
+0

필요가 없습니다,하지만 그렇지 않으면이 좋은 해결책처럼 들린다. – coreyward

+0

coreyward가 맞습니다. – ctcherry

+0

그래, 내가 그걸 끝내고 돌아간거야. 왜 처음에 직접 메소드를 호출하는 대신에'append_before_filter'를 사용하기로 결심했는지 잘 모르겠습니다! –