method for dynamic secret signing rather than globally configured secret about jwt

[kamilmysliwiec]

Published as 6.1.0

[kamilmysliwiec]

I'm not a robot @tomsiwik. I have already pulled your branch and after a few changes, will very likely merge it soon. I'm sorry for inconveniences.

[tomsiwik]

Ofc, I'll try over the weekend. Barely any time left.

[kamilmysliwiec]

Would you be interested in creating a PR for this feature? :)

[kamilmysliwiec]

Awesome, looking forward.

[tomsiwik]

I'm confused as to where my PR and this issue/feature is going. Do I need to reply/ inform somebody about it? Am I missing something in the contribution guide what might cause this block? I have added tests, as far as I know this is not a mono-repo build dependancy (or is it?).

How or should I perform (unclear if this is relevant for external packages): https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md#commonly-used-npm-scripts

Some questions, no further notes and a pending PR which I am forced to watch weekly (since end of march) as the renovate task races me to fix the conflicts in the package.jsondue to version missmatches.

[tomsiwik]

No problem... maybe I should rephrase it, I did not want to sound negative. I am just confused where this was going. A simple note would have been enough. I don't mind to update the deps. For me it just wasn't clear if the package.json conflicts were causing this delay. Thanks for answering so quickly though.

[cheelahim]

@tomsiwik @kamilmysliwiec Hey guys! Thanks for this feature. I just had a change to play with the new secretOrKeyProvider option and I have a question. Here is current implementation:

  sign(payload: string | Buffer | object, options?: jwt.SignOptions): string {
    const signOptions = this.mergeJwtOptions(
      options,
      'signOptions'
    ) as jwt.SignOptions;
    const secret = this.getSecretKey(
      payload,
      options,
      'privateKey',
      JwtSecretRequestType.SIGN
    );

    return jwt.sign(payload, secret, signOptions);
  }

Don't you think it would be better to call getSecretKey with signOptions (merged) instead of options? Otherwise verifyOrSignOrOptions argument of secretOrKeyProvider doesn't have access to the default options. Basically it affects all methods where getSecretKey is used.

As a temporary workaround all options can merged outside of JwtService and passed as the desired method argument, but that is not very convenient of course.