From 8e6cbcbb8bf7d07844f8ea097eed4326294b454b Mon Sep 17 00:00:00 2001 From: Evan Higgins Date: Mon, 29 Jul 2019 21:34:02 -0500 Subject: [PATCH] docs(authentication) URL and type fix Update exception filter docs link and fix return type in example --- content/techniques/authentication.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/techniques/authentication.md b/content/techniques/authentication.md index 755453585e..30aa44ac50 100644 --- a/content/techniques/authentication.md +++ b/content/techniques/authentication.md @@ -227,7 +227,7 @@ export class LocalStrategy extends PassportStrategy(Strategy) { super(); } - async validate(username: string, password: string): any { + async validate(username: string, password: string): Promise { const user = await this.authService.validateUser(username, password); if (!user) { throw new UnauthorizedException(); @@ -263,7 +263,7 @@ We've followed the recipe described earlier for all Passport strategies. In our We've also implemented the `validate()` method. For each strategy, Passport will call the verify function (implemented with the `validate()` method in `@nestjs/passport`) using an appropriate strategy-specific set of parameters. For the local-strategy, Passport expects a `validate()` method with the following signature: `validate(username: string, password:string): any`. -Most of the validation work is done in our `AuthService` (with the help of our `UserService`), so this method is quite straightforward. The `validate()` method for **any** Passport strategy will follow a similar pattern, varying only in the details of how credentials are represented. If a user is found and the credentials are valid, the user is returned so Passport can complete its tasks (e.g., creating the `user` property on the `Request` object), and the request handling pipeline can continue. If it's not found, we throw an exception and let our exceptions layer handle it. +Most of the validation work is done in our `AuthService` (with the help of our `UserService`), so this method is quite straightforward. The `validate()` method for **any** Passport strategy will follow a similar pattern, varying only in the details of how credentials are represented. If a user is found and the credentials are valid, the user is returned so Passport can complete its tasks (e.g., creating the `user` property on the `Request` object), and the request handling pipeline can continue. If it's not found, we throw an exception and let our exceptions layer handle it. Typically, the only significant difference in the `validate()` method for each strategy is **how** you determine if a user exists and is valid. For example, in a JWT strategy, depending on requirements, we may evaluate whether the `userId` carried in the decoded token matches a record in our user database, or matches a list of revoked tokens. Hence, this pattern of sub-classing and implementing strategy-specific validation is consistent, elegant and extensible.