Skip to content

Commit

Permalink
Merge pull request nestjs#552 from evdhiggins/evdhiggins/authentication
Browse files Browse the repository at this point in the history
docs(authentication): URL and type fix
  • Loading branch information
kamilmysliwiec authored Jul 30, 2019
2 parents bfd4c78 + 8e6cbcb commit 2ef4f4a
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions content/techniques/authentication.md
Original file line number Diff line number Diff line change
Expand Up @@ -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<any> {
const user = await this.authService.validateUser(username, password);
if (!user) {
throw new UnauthorizedException();
Expand Down Expand Up @@ -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 <a href="exceptions">exceptions layer</a> 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 <a href="exception-filters">exceptions layer</a> 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.

Expand Down

0 comments on commit 2ef4f4a

Please sign in to comment.