Perguntas[nestjs](coding)

Tenho as seguintes habilidades definidas em CaslAbilityFactory:

    if (auth.isAdmin) {
      can(Action.Create, User);
      can(Action.Read, "all");
      can(Action.Manage, User);
      can(Action.Update, User, ["email", "firstName", "lastName", "role"]);

      can(Action.Delete, User);
      cannot(Action.Delete, User, isOwner);
    }

    if (auth.isUser) {
      can([Action.Read, Action.Update], User, isOwner);
    }

Então, defini o seguinte resolver:

  @Mutation(() => User)
  @UseGuards(PoliciesGuard)
  @CheckPolicies(ability => ability.can(Action.Update, User))
  async updateUser(
    @Args("input") input: UpdateUserInput,
    @CurrentAuth() auth,
  ): Promise<User> {
    const ability = this.caslAbilityFactory.createForAuth(auth);

    if (ability.cannot(Action.Update, { id: input.id }) {
      throw new ForbiddenException();
    }

    return this.usersService.update(input.id, input);
  }

O @CheckPoliciesdecorador garante corretamente que apenas um usuário com a Updateação para usuários pode chamá-lo, mas preciso afirmar que para este específico, posso atualizá-lo? Se o solicitante for o proprietário, ele pode. Mas como você verifica isso antes de carregar o usuário?

Uma solução óbvia é carregar o usuário, executar a verificação e, então, executar a atualização. Outra solução mais hackeada seria, de alguma forma, fazer o cast new User({ id })e executar a verificação.

Existe uma solução melhor para isso?

Obrigado,

Por Design, em nossas APIs RESTful, usamos HEAD para verificar a existência de uma entidade. Recentemente, me deparei com um problema ao usar NestJS e usar o Tipo de Solicitação Http de HEAD e GET com a Mesma Rota. Por algum motivo, quando o cliente faz uma solicitação HEAD http para a API, digamos HEAD - /api/test, ela rotearia para o controlador da porção GET do código. Após alguma solução de problemas, parece estar relacionado à posição do método no controlador. Se você colocar a porção HEAD do código do controlador após o GET, a solicitação interceptará a solicitação GET. Se você colocá-la depois, funcionará conforme o esperado. Não sei por que, mas é bom saber

Trecho de código:

// HEAD must be before GET for NestJS controller with the same route
@Head(':id')  // check for the existence of an entity
  async hasOne(@Res() response, @Param('id') id): Promise<any> {

   // do something
  }

  @Get(':id') // Get a single entity
  getOne(@Param('id') id): Promise<any> {

   // do something
  }

Estamos usando o NestJS 10.4.4

insira a descrição da imagem aqui. Tenho esse erro nos codespaces do github e na minha máquina local (windows 11). A versão do nó é 20 Package.json como novo padrão. Todo esse padrão do nestcli, exceto o arquivo elsinore. Eu adiciono uma regra mais bonita.

Quero gerar o módulo nestjs.

Estou tentando registrar o objeto de solicitação (para fins de depuração). Meu aplicativo NestJS usa express (a opção padrão).

Obtenho o objeto request tanto no meu controlador quanto no provedor de serviços (após a injeção neste último caso). A parte relevante no controlador é:

  // this is the Logger from @nestjs/common
  private readonly logger = new Logger(MessagesController.name);
  
  @Get()
  findAll(@Req() request: Request): string
  {
    this.logger.log(request);
    return this.messagesService.findAll();
  }

Parte relevante no provedor de serviços é:

// the service is request-scoped since it's injected with a request-scoped provider
@Injectable({scope: Scope.REQUEST})
export class MessagesService {

  constructor(@Inject(REQUEST) private request: Request) {
    this.request = request;
  }

  findAll(): string {
    this.logger.log(this.request);
    return "all messages";
  }

}

Em ambos os casos em que ocorre o registro (ou seja, tanto no controlador quanto no serviço), o objeto é registrado no console simplesmente como [object Object]o que não ajuda em nada. Se as chamadas para this.logger.log(request)forem substituídas por mundanas, console.log(request)o objeto será bem impresso no console.

Como posso obter o Loggerfrom @nestjs/commonpara imprimir bem esses objetos de solicitação?

Preciso compartilhar um módulo dinâmico. Na documentação descobri que podemos compartilhar serviços no escopo global. Sim, esta é uma solução. No entanto, gostaria de saber se isso é possível no nível do módulo. É por isso que estou interessado no que acontece quando o módulo dinâmico é registrado algumas vezes . Na prática, vejo que ele cria diferentes instâncias de módulos no NestJS. O comportamento do módulo é diferente do Angular, porém o NestJS gosta de mencionar a semelhança Angular. O módulo de propriedade me leva embora. Agora entendo que é usado apenas para controlar o comportamento do módulo. No entanto, não vejo nenhuma explicação na documentação. Eu vi perguntas semelhantes. Mas não encontrei detalhes que me interessem.

O código a seguir é apenas uma ideia. Não foi verificado.

import { DynamicModule, Module } from '@nestjs/common';
import { ConfigService } from './config.service';

@Module({})
export class ConfigModule {
  static register(options: Record<string, any>): DynamicModule {
    return {
      module: ConfigModule,
      providers: [
        {
          provide: 'CONFIG_OPTIONS',
          useValue: options,
        },
        ConfigService,
      ],
      exports: [ConfigService],
    };
  }
}

export const ConfiguredConfigModule = ConfigModule.register({key: 'flower'});
... 

@Module({
  imports: [ConfiguredConfigModule]
})
export class AppModule {}

Cumprimentos.

Estou com um problema muito estranho com meu aplicativo Nest (moro dentro do Nx, pelo que vale a pena). Eu gerei um novo recurso:

nx g resource --project testing
✔ Which generator would you like to use? · @nx/nest:resource
✔ What name would you like to use for this resource (plural, e.g., `users`)? · items
✔ What transport layer do you use? · graphql-code-first
✔ Would you like to generate CRUD entry points? (Y/n) · false

Foi adicionado Importsno app.module principal:

@Module({
  imports: [
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      playground: false,
      plugins: [ApolloServerPluginLandingPageLocalDefault()],
      autoSchemaFile: "schema.gql",
    }),
    ItemsModule,
  ],
})
export class AppModule {}

Em seguida, adicionei um resolvedor simples para deixar o GraphQL satisfeito:

// ./items/items.resolver.ts
import { Int, Query, Resolver } from "@nestjs/graphql";

import type { ItemsService } from "./items.service";

@Resolver()
export class ItemsResolver {
  constructor(private readonly service: ItemsService) {}

  @Query(() => [Int])
  getAll() {
    return [1, 2, 3];
  }
}

Então meu items.module fica assim:

import { ItemsResolver } from "./items.resolver";
import { ItemsService } from "./items.service";

@Module({
  providers: [ItemsResolver, ItemsService],
})
export class ItemsModule {}

o que é bastante válido para mim. Mas mesmo assim, ainda estou conseguindo Error: Nest can't resolve dependencies of the ItemsResolver (?). Please make sure that the argument Object at index [0] is available in the ItemsModule context.

Se eu remover o serviço da ItemsResolverclasse, tudo funcionará bem.

Eu encontrei este erro ao tentar executar npm install @nestjs/microservices :

# npm resolution error report

While resolving: [appName]
Found: @nestjs/common@9.4.3
node_modules/@nestjs/common
  @nestjs/common@"^9.4.3" from the root project

Could not resolve dependency:
peer @nestjs/common@"^10.0.0" from @nestjs/microservices@10.1.3
node_modules/@nestjs/microservices
  @nestjs/microservices@"*" from the root project

Fix the upstream dependency conflict, or retry
this command with --force or --legacy-peer-deps
to accept an incorrect (and potentially broken) dependency resolution.

Estas são minhas dependências em package.json:

"dependencies": {
    "@nestjs/cache-manager": "^2.1.0",
    "@nestjs/common": "^9.4.3",
    "@nestjs/config": "^3.0.0",
    "@nestjs/core": "^9.0.0",
    "@nestjs/passport": "^10.0.0",
    "@nestjs/platform-express": "^9.4.3",
    "@nestjs/swagger": "^7.0.12",
    "@nestjs/typeorm": "^10.0.0",
    "bcryptjs": "^2.4.3",
    "cache-manager": "^5.2.3",
    "class-transformer": "^0.5.1",
    "class-validator": "^0.14.0",
    "dotenv": "^16.3.1",
    "express-session": "^1.17.3",
    "jsonwebtoken": "^9.0.0",
    "passport": "^0.6.0",
    "passport-google-oauth20": "^2.0.0",
    "pg": "^8.11.1",
    "reflect-metadata": "^0.1.13",
    "rxjs": "^7.2.0",
    "typeorm": "^0.3.17"
  },

Tentei usar --legacy-peer-deps , mas não compila e não quero usar --force . Se alguém tiver ideia do que consertar, ficarei extremamente grato.

Estou tendo problemas com guardas globais, interceptores e filtros que funcionam durante o tempo de execução, mas não funcionam durante o teste e2e.

Aqui está um exemplo de uma configuração de guarda. O problema é o mesmo para todos os itens do tipo middleware, eles não são acionados a menos que eu os especifique localmente para cada controlador, etc.

Meu módulo principal:

@Module({
  imports: [
    JwtModule.register({
      secret: JWT_PASS,
      global: true,
    }),
    BoothModule,
    SessionTypeModule,
  ],
  providers: [
    {
      provide: APP_GUARD,
      useClass: AuthenticationGuard,
    },
  ],
})
export class AppModule {}

Um guarda:

@Injectable()
export class AuthenticationGuard implements CanActivate {
  private readonly log = new Logger('AuthenticationGuard');

  constructor(private readonly jwtService: JwtService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
     console.log('triggered?!');
     ....
     return true;
  }

O log do console funciona, os testes falham quando a lógica de guarda falha.

beforeAll(async () => {
    const moduleFixture = await Test.createTestingModule({
      imports: [
        AppModule,
        ClientsModule.register([
          {
            name: '<name>',
            transport: Transport.GRPC,
            options: {
              url: 'localhost:5001',
              package: '<package>',
              protoPath: '<path>',
              credentials: GRPC.ChannelCredentials.createInsecure(),
            },
          },
        ]),
      ],
    }).compile();

    app = moduleFixture.createNestApplication();

    app.useGlobalInterceptors(new ExceptionInterceptor());
    app.connectMicroservice<MicroserviceOptions>({
      transport: Transport.GRPC,
      options: {
        url: 'localhost:5001',
        package: SPEEDPHOTO_PACKAGE_NAME,
        protoPath: BOOTH_PROTO,
      },
    });

    await app.startAllMicroservices();

    await app.init();

    const clientGrpc: ClientGrpc = app
      .getMicroservices()[0]
      .get(BOOTH_SERVICE_NAME);
    client = clientGrpc.getService<BoothServiceClient>(BOOTH_SERVICE_NAME);
  });

Ele só falha durante o teste.