2011-04-27 113 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