passport.authenticate('github');

이 정책 중 하나를 설정할 때, 매개 변수와 검증 리셋 함수를 정의해야 합니다. 이 함수는 프로그램에서 되돌아오는 사용자 데이터를 처리합니다

적어도 나에게 이상한 것은 두 개의 다른 노선에서 passport.authenticate()으로 전화를 걸었던 이유

하지만 비결은:

authenticate()을 처음 호출할 때passport는 이전에 등록된 함수에 전달된 문자열 이름을 통해 정책이 있는지 확인하려고 시도합니다.만약 그렇다면, 공급자의 권한 수여 단점을 클릭하여 OAuth 춤을 시작합니다.만약 찾을 수 없다면, 전략이 알 수 없다는 오류 하나만 던집니다.p>

현재 두 번째 호출은 공급자의 OAuth 서버에서 리셋 중입니다. 루트로 리셋 중입니다.이번에는 완전히 똑같아 보이지만, 패스포트는 OAuth 흐름의 두 번째 단계를 감지하고, OAuth 영패를 요청하기 위해 방금 얻은 임시 코드를 사용하는 정책을 알려 줍니다.그 전략은 어떻게, 어디서 요구를 하는지 정확히 알고 있다.

이후에 무슨 일이 일어날지

세계로 가는 길

PassportJS의 OAuth 흐름에 대한 나의 최신 손그림 작품을 보십시오.이때 우리는 getProfile():

예전보다 더 곤혹스러우면 계속 읽으세요.나는 반드시 좋아질 것이다

OAuth 영패를 받은 후 가장 먼저 발생한 일은 이 정책이 사용자의 프로필을 가져오는 것입니다.이것은 정책의 내부 메커니즘으로 어느 특정한 공급자에게 그것을 요청하는지 알고 있습니다



이어서 이 전략은 개요 파일을 내부에서 이 공급자가 정의한 모델로 해석한 다음에 그가 가지고 있는 모든 다른 데이터(accessToken,refreshToken과 개요 파일)와 함께 우리의verify 리셋에 전달하려고 시도한다

정책을 설정할 때 인증 리셋을 정의한 것을 기억하십니까?현재 우리의 사용자 정의 코드가 처음으로 이 정책에 의해 실행되었다.이 예에서 우리는 이 사용자의 데이터베이스를 검사하고 필요할 때 기록을 작성하며 필요한 기타 내용을 검증할 수 있다

필요한 모든 매개 변수를 검사한 후, 우리는done(또는verify callback의 리셋 함수)를 호출할 것입니다. 이것은 그의 네 번째이자 마지막 함수 매개 변수입니다.우리는 null(오류 없음)과 우리가 생각하는 모든 정보를 사용자에게 전달합니다

(accessToken, refreshToken, profile, done) => {
  // verify things here and then...
  done(null, {accessToken, profile})
}

passport.serializeUser((user, done) => done(null, {
  id: user.profile.id,
  accessToken: user.access_token
}))

passport.deserialize((user, done) => {
  dbHelper.getUser(user.id)
    .then(profile => done(profile))
})

server.use(passport.initialize())
server.use(passport.session())