Unknown authentication strategy "jwt" when use Request Scope Service

[v1d3rm3]

I'm submitting a...

[ ] Regression 
[X] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

When i import in JwtStrategy a service that has Request Scope, authentication does not work anymore, as i show in this repository: https://github.com/victorschinaider/nest-request-auth-bug.

Expected behavior

I expect that i can use request scope service in JwtStrategy.

Minimal reproduction of the problem with instructions

In repository: https://github.com/victorschinaider/nest-request-auth-bug

What is the motivation / use case for changing the behavior?

Environment

Nest version: 6.0.0

 
For Tooling issues:
- Node version: 11
- Platform:  Ubuntu

Others:

[iangregsondev]

You are not lone here, I also had the same issue. I don't have a solution, i have been playing around with it for hours and no go.

[kamilmysliwiec]

You cannot use request scoped providers in passport strategy because passport itself is global (the package is not compatible with this feature). Hopefully, we will provide a more flexible @nestjs/auth package soon.

[marcus-sa]

Is a more flexible @nestjs/auth package on the roadmap? @kamilmysliwiec
Had to do some annoying workarounds with middleware and request context to get this working 💯

[ricardosaracino]

I was so excited i could make a logger scoped with the request .... only to be extremely disappointed.

Have a stack question open if anyone wants to chime in

https://stackoverflow.com/questions/57714282/log-session-user-nodejs-nestjs

[nurikabe]

Documentation at https://docs.nestjs.com/techniques/authentication should probably be updated to make this issue clear.

[yaser-ali-s]

What are some of the workarounds people have come up with? I was wondering if using a middleware instead of using provider scope works as a workaround?

Update: @eropple/nestjs-auth exists, and it uses interceptors, as opposed to middleware.

[ricardosaracino]

@yaser-ali-s .. .made 2 loggers with different scopes and manually passed in the request where appropriate

@Injectable({scope: Scope.REQUEST})
export class AppLoggerService extends AbstractLoggerService {

    constructor(@Inject(REQUEST) private readonly req) {
        super();
    }

    public debug(message: string | object) {
        this._log('debug', this.req, message);
    }

    public log(message: string | object) {
        this._log('info', this.req, message);
    }

    public warn(message: string | object, trace?: string) {
        this._log('warn', this.req, message, trace);
    }

    public error(message: string | object, trace?: string) {
        this._log('error', this.req, message, trace);
    }
}

@Injectable({scope: Scope.DEFAULT})
export class GlobalLoggerService extends AbstractLoggerService {
}

xport abstract class AbstractLoggerService implements LoggerService {

    public static default = log4js.getLogger('default');

    private static trace() {

        const e = new Error();

        const fileMatch = e.stack.split('at ')[4].match(/(\\.*\\)(.*)\)/);

        if (fileMatch) {
            const callee = e.stack.split('at ')[4].match(/(.*) /)[1];
            return {callee, file: fileMatch[2]};
        }

        const file = e.stack.split('at ')[4].match(/.*\\(.*)/)[1];
        return {callee: '', file};
    }

    private static makeString(message) {
        if (typeof message !== 'string') {
            return JSON.stringify(message, null, 2);
        }

        return message;
    }

    protected _log(func: string, req: any, message: string | object, trace?) {

        const call = AbstractLoggerService.trace();

        if (req) {
            /**
             * https://stackoverflow.com/questions/48618450/get-client-ip-in-azure-through-mvc-5-controller
             * X-Forwarded-For: <client>, <proxy1>, <proxy2>
             *
             * Azure returning
             * "x-forwarded-for": "172.16.129.130, 198.103.109.141:17075, 198.103.109.141, 198.103.109.141:0, 13.71.170.128:6848",
             */
            AbstractLoggerService.default.addContext('ip', req.headers['x-forwarded-for'] ? req.headers['x-forwarded-for'] : req.ip);
            AbstractLoggerService.default.addContext('user', req.user ? req.user.id : '');

        } else {
            AbstractLoggerService.default.addContext('ip', '');
            AbstractLoggerService.default.addContext('user', '');
        }

        AbstractLoggerService.default.addContext('callee', call.callee);
        AbstractLoggerService.default.addContext('file', call.file);

        if (trace) {
            AbstractLoggerService.default[func](AbstractLoggerService.makeString(message), trace);
        } else {
            AbstractLoggerService.default[func](AbstractLoggerService.makeString(message));
        }

    }

    public debug(message: string | object) {
        this._log('debug', null, message);
    }

[unckleg]

Any news on this one ? Any service dependent on Request scope will break the passport.

[alexey-nobody]

Any news?

[kamilmysliwiec]

This is not a bug. You cannot use request scoped providers in passport strategy because passport itself is global (the package is not compatible with this feature). Hopefully, we will provide a more flexible @nestjs/auth package soon.