Rails4+DeviseTokenAuth重写SessionsController拒锁用户访问报错

你遇到的Abstract相关错误应该是AbstractController::DoubleRenderError，根源在于你调用super之后，DeviseTokenAuth的create方法已经完成了响应渲染（比如返回登录成功的JSON和token），这时候你再执行render就触发了Rails的双重渲染限制。下面给你两种更合理的解决方案：

方案一：利用Devise的模型层验证（推荐） #

Devise本身提供了active_for_authentication?方法，用来判断用户是否具备登录权限。我们可以在User模型里重写这个方法，直接拦截锁定状态的用户：

class User < ActiveRecord::Base
  # 保留你原本的Devise模块配置
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable,
         :token_authenticatable # 适配DeviseTokenAuth的模块

  # 重写Devise的登录权限验证方法
  def active_for_authentication?
    # 先执行Devise默认的验证（比如用户是否已激活），再额外检查状态是否未锁定
    super && status.to_sym != :locked
  end

  # 自定义未通过验证时的错误提示
  def inactive_message
    status.to_sym == :locked ? :locked : super
  end
end

这样配置后，当用户处于锁定状态时，DeviseTokenAuth会自动拒绝登录请求，返回对应的未授权响应，不需要修改控制器代码，更符合Devise的设计规范。

方案二：在控制器中提前拦截（适合需要自定义响应的场景） #

如果你需要完全自定义错误响应内容，可以在create方法里先检查用户状态，再决定是否执行DeviseTokenAuth的默认逻辑：

class SessionsController < DeviseTokenAuth::SessionsController
  def create
    # 根据登录参数查找用户（复用DeviseTokenAuth的查找逻辑）
    @resource = resource_class.find_for_database_authentication(email: params[:email])

    # 检查用户是否存在且状态为锁定
    if @resource&.status&.to_sym == :locked
      render json: { error: "Account is locked MOFO " }, status: :unauthorized
    else
      # 状态正常，执行DeviseTokenAuth的默认登录逻辑
      super
    end
  end
end

这种方式避免了双重渲染问题，因为我们在执行super之前就提前返回了错误响应，不会触发后续的默认渲染流程。

为什么你的原代码会报错？ #

DeviseTokenAuth的create方法内部已经完成了响应处理：如果登录成功，它会渲染包含token的JSON；如果失败，也会返回对应的错误响应。当你调用super之后，Rails已经标记了响应已发送，此时再调用render就会触发AbstractController::DoubleRenderError，也就是你遇到的Abstract相关错误。

内容的提问来源于stack exchange，提问作者Mike W