Loopback 4的CrudRestController端点能否添加Authorization装饰器？

不需要为每个模型手动编写所有端点代码，也不是只能使用Authorizer函数，有两种可落地的正规实现方案：

方案1：继承基础CrudRestController，重写对应端点附加装饰器 #

该方案符合官方语法规范，无黑盒逻辑，只需对需要加权限的端点重写、复用父类原有CRUD逻辑即可，工作量极小，示例代码：

import { CrudRestController } from '@loopback/rest-crud';
import { repository } from '@loopback/repository';
import { authorize } from '@loopback/authorization';
import { Product, ProductRepository } from '../';

// 定义基础CRUD控制器配置
const ProductControllerBase = CrudRestController<
  Product,
  typeof Product.prototype.id,
  {}
>(Product, { basePath: '/products' });

export class ProductController extends ProductControllerBase {
  constructor(
    @repository(ProductRepository)
    protected repository: ProductRepository,
  ) {
    super(repository);
  }

  // 仅重写需要加权限的方法，逻辑完全复用父类
  @authorize({ allowedRoles: ['admin'] })
  async create(...args: Parameters<ProductControllerBase['create']>) {
    return super.create(...args);
  }

  @authorize({ allowedRoles: ['user', 'admin'] })
  async find(...args: Parameters<ProductControllerBase['find']>) {
    return super.find(...args);
  }
}

该方案适合不同模型、不同端点需要配置独立权限规则的场景

方案2：使用全局授权器（Authorizer）做统一权限管控 #

如果你的权限规则支持全局抽象（比如所有写操作需要管理员权限、读操作普通用户可访问，或按模型名称匹配权限），用全局Authorizer反而更简洁，不需要给每个控制器单独加装饰器，示例代码：

import { AuthorizationContext, AuthorizationDecision, AuthorizationMetadata, Authorizer } from '@loopback/authorization';
import { inject, Provider } from '@loopback/core';

export class MyAuthorizer implements Provider<Authorizer> {
  value(): Authorizer {
    return this.authorize.bind(this);
  }

  async authorize(
    context: AuthorizationContext,
    metadata: AuthorizationMetadata,
  ): Promise<AuthorizationDecision> {
    // 从上下文中获取当前请求的接口信息
    const operationName = context.operation.name;
    const controllerName = context.operation.targetName;
    const currentUserRoles = context.principals[0]?.roles ?? [];

    // 示例规则：所有CrudRestController的写操作接口需要admin权限
    if (
      controllerName.includes('CrudRestController') &&
      ['create', 'replaceById', 'updateById', 'deleteById'].includes(operationName)
    ) {
      return currentUserRoles.includes('admin') ? AuthorizationDecision.ALLOW : AuthorizationDecision.DENY;
    }

    // 其他接口默认放行
    return AuthorizationDecision.ALLOW;
  }
}

完成授权器逻辑后在Application中注册即可生效。
该方案适合大量CrudRestController需要统一配置权限的场景，代码维护成本更低

注意事项 #

• 不要直接修改CrudRestController的源码，后续框架版本升级会覆盖自定义修改
• 所有原有CRUD逻辑均可复用，无需手动重复编写业务代码
• 单模型权限差异大优先选方案1，全局规则统一优先选方案2

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