2011-04-27 151 views
1

我有一個控制器,基於登錄用戶在兩個不同的「上下文」中運行(基本上,用戶可以在他們自己的帳戶上執行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 2011-04-27 17:54:22

+0

coreyward是對的,我只是非常明確! – ctcherry 2011-04-27 17:55:02

+0

是的,這就是我最終做的(沒有'return's)。我不確定爲什麼我決定使用'append_before_filter'而不是直接調用方法! – 2011-04-27 17:55:20