覆盖AuthorizationsController门卫

Question

我正在压倒门卫AuthorizationsController.正如文档建议我继承自AuthorizationsController.现在,下面的代码显示了我对覆盖的最新尝试.

我现在有什么

基本上,在新的Authorization Doorkeeper流程周围添加额外的if语句.我添加了第3-7行,目前工作正常.:error如果第6行等于true,它返回我.

我的问题

我仍然可以通过浏览器URL和服务器日志看到AccessToken.因此,作为用户,我仍然可以使用此AccessToken来检索Postman中的某些数据.甚至在登录时它给我一个错误.这是为什么？我怎么能防止这种情况发生？

class AuthorizationsController < Doorkeeper::AuthorizationsController
  def new
    application = Application.find(authorization.authorize.pre_auth.client.id)
    resource_owner = User.find(current_resource_owner)

    if application.users.exclude?(resource_owner) && application.owner != resource_owner
      render :error
    elsif pre_auth.authorizable?
      if skip_authorization? || matching_token?
        auth = authorization.authorize
        redirect_to auth.redirect_uri
      else
        render :new
      end
    else
      render :error
    end
  end

end

如果您查看DigitalOcean编写的OAuth2 简介,我的if语句仍然在第3步"用户代理接收带有重定向URI的访问令牌"上成功,因为我可以在浏览器URL中看到带有重定向URI的AccessToken.在第3步之后,它给了我:error.

UPDATE

生成AccessToken的整个过程在我的覆盖AuthorizationsController启动之前已经完成.我添加了一个简单before_action的打印到服务器日志,但在此之前Doorkeeper::AccessToken Load (0.9ms) SELECT 'oauth_access_tokens'.* FROM 'oauth_access_tokens' WHERE 'oauth_access_tokens'.'token' = 'x' LIMIT 1.

Answer 1

您假设您在浏览器 URL 中看到的令牌是 OAuth access_token。它实际上只是一个JWT（JSON Web Token）。我假设此令牌是某种会话令牌，因为 Doorkeeper 尚未授权用户使用该应用程序。您错误地假设您的 OAuth 流程到达“用户代理通过重定向 URI 接收访问令牌”步骤。

您的网址中的令牌根本没有害处，因此您没有理由阻止您的应用程序发出令牌。如果用户中断会话，则令牌将变得毫无用处。

希望这可以帮助 ：）