设计 - 用户编辑电子邮件后确认

Question

我一直试图解决这个问题2天.我正在通过电子邮件确认确认用户帐户(通过Devise).我终于完成了所有工作,但重点是确认一个人拥有他们声称拥有的电子邮件.因此,每当用户更改其电子邮件时,我都需要再次确认.

为了做到这一点,我已经创建registrations_controller并编写了该update方法.主要基于Devise的基础,但我检查是否需要根据更新发送确认.

# registrations_controller.rb
def update
  self.resource = resource_class.to_adapter.get!(send(:"current_#{resource_name}").to_key)

  send_confirmation = false
  if params[:user][:email] != resource.email
    send_confirmation = true
  end

  if resource.update_with_password(params[resource_name])
    set_flash_message :notice, :updated if is_navigational_format?
    sign_in resource_name, resource, :bypass => true

    if send_confirmation
      resource.update_attributes(:confirmed_at => nil, :confirmation_sent_at => nil)
      resource.send_confirmation_instructions        
    end

    respond_with resource, :location => after_update_path_for(resource)
  else
    clean_up_passwords(resource)
    respond_with_navigational(resource){ render_with_scope :edit }
  end
end

我的问题是我不知道在哪个过程中能够改变重定向的位置.我有一个页面说明"已发送电子邮件以确认您的电子邮件".但是,如果我send_confirmation_instructions在用户点击"更新帐户" 后尝试将其删除,则会将其注销(推送到登录屏幕),然后当他们通过电子邮件确认帐户时,会将其定向到我想要显示的页面他们.

我有一个定制的Warden策略,其中有一些放入其中,我还编写了Devise放入的前过滤器:

# registrations_controller.rb
def authenticate_scope!
  puts "RegistrationsController :: authenticate_scope!"
  puts "action : #{params[:action]}"

  super
end

所以看起来它正在尝试验证用户.日志内容如下:

...
Redirected to http://localhost:3000/users/edit
Completed 302 Found in 3537ms
RegistrationsController :: authenticate_scope!
action : edit


Started GET "/users/edit" for 127.0.0.1 at 2011-06-08 11:42:09 -0500
  Processing by RegistrationsController#edit as HTML
  User Load (0.7ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 19 LIMIT 1
Completed   in 83ms
Warden::Strategies authenticate!
Warden::Strategies params: {"action"=>"new", "controller"=>"sessions"}


Started GET "/users/sign_in" for 127.0.0.1 at 2011-06-08 11:42:10 -0500
  Processing by SessionsController#new as HTML
...

那么我如何/在哪里控制重定向到哪里？我正确地重置了"确认"属性吗？

Answer 1

我们遇到了类似的问题(主要是因为确认的用户在我们的系统中并不是真正的批准用户) - 并且决定采用user_status属性.它有2种状态 - "待定",已经确认但尚未批准,并且"已批准".如果由于某种原因用户不再被批准(在您的情况下,他们更改了他们的电子邮件地址),那么我们将他们更改回待处理.

我们在applicationController上有一个before_filter,根据它们的状态来验证它们应该去哪里.

def check_user_status
if current_user #logged in
 case current_user.status
   when "pending" 
     redirect_to root_path #user hasn't been approved yet
   when "approved"
     #tracking logic here   
  end
 end
end

希望这可以帮助.

Answer 2

捆绑更新设计.这已在当前发布的版本(2.0)中修复