如何向Pundit作用域传递额外上下文信息？

更优雅的上下文传递方案 #

完全理解你的顾虑——给User模型临时加current_portal属性的做法确实是权宜之计，当后续需要加入更多授权上下文（比如角色组、时间范围等）时，这种方式会让用户模型变得臃肿，还可能引发线程安全问题（比如多请求并发时的属性污染）。下面是几个更健壮的替代方案：

1. 给policy_scope传递额外参数 #

Pundit的policy_scope方法支持传递额外的关键字参数，你可以直接把门户信息传到Scope类中，不需要修改用户模型：

控制器代码

# app/controllers/posts_controller.rb
def index
  @portal = Portal.find(params[:portal_id])
  @posts = policy_scope(Post, portal: @portal)
end

Scope类代码

# app/policies/post_policy.rb
class PostPolicy < ApplicationPolicy
  class Scope < Scope
    def initialize(user, scope, portal:)
      super(user, scope)
      @portal = portal
    end

    def resolve
      # 直接使用@portal过滤权限范围内的记录
      if user.can_view_unpublished_posts?(@portal)
        scope.where(portal: @portal)
      else
        scope.where(portal: @portal, published: true)
      end
    end
  end
end

这种方式直接明了，上下文传递清晰，适合简单的多上下文场景。

2. 扩展Pundit的上下文对象 #

如果你的应用需要在多个Policy/Scope中复用门户（或其他）上下文，推荐扩展Pundit的上下文，而不是污染用户模型。你可以在ApplicationController中自定义pundit_user方法，返回一个包含用户和当前门户的复合对象：

控制器配置

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  include Pundit::Authorization

  def pundit_user
    # 用OpenStruct或自定义Context类封装上下文
    OpenStruct.new(
      user: current_user,
      current_portal: current_portal # 假设你已有获取当前门户的方法
    )
  end

  private

  def current_portal
    @current_portal ||= Portal.find(params[:portal_id])
  end
end

修改Policy和Scope类

# app/policies/post_policy.rb
class PostPolicy < ApplicationPolicy
  # 现在context是自定义对象，包含user和current_portal
  def show?
    if context.user.can_view_unpublished_posts?(context.current_portal)
      record.portal == context.current_portal
    else
      record.portal == context.current_portal && record.published?
    end
  end

  class Scope < Scope
    def resolve
      if context.user.can_view_unpublished_posts?(context.current_portal)
        scope.where(portal: context.current_portal)
      else
        scope.where(portal: context.current_portal, published: true)
      end
    end
  end
end

这是Pundit官方推荐的多上下文处理方式，扩展性极强——后续需要加入更多上下文（比如current_team、current_role），只需要修改pundit_user返回的对象即可，不会影响用户模型的纯净性。

3. 封装权限逻辑到独立服务类 #

如果你的权限逻辑非常复杂（比如多上下文组合判断、跨模型权限关联），可以把权限判断封装到专门的服务类中，让Policy和Scope仅作为授权入口，解耦复杂逻辑：

权限服务类

# app/services/user_portal_permissions.rb
class UserPortalPermissions
  def initialize(user, portal)
    @user = user
    @portal = portal
  end

  def can_view_unpublished_posts?
    # 这里可以写复杂的权限判断，比如关联用户在门户中的角色
    @user.portal_roles.find_by(portal: @portal)&.can_view_unpublished?
  end

  def accessible_posts
    can_view_unpublished_posts? ? @portal.posts : @portal.posts.published
  end
end

在Policy和Scope中使用服务

# app/policies/post_policy.rb
class PostPolicy < ApplicationPolicy
  def show?
    permissions = UserPortalPermissions.new(context.user, context.current_portal)
    permissions.can_view_unpublished_posts? || record.published?
  end

  class Scope < Scope
    def resolve
      permissions = UserPortalPermissions.new(context.user, context.current_portal)
      permissions.accessible_posts
    end
  end
end

这种方式让权限逻辑更易于测试和维护，后续修改权限规则时，只需要调整服务类即可，不需要改动Policy或控制器代码。

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