위 챗 애플 릿 침묵 로그 인 및 사용자 정의 로그 인 상태 유지 설명

1.배경
애플 릿 에서 openid 는 사용자 가 애플 릿/공공 번호 에 대한 표지 입 니 다.개발 자 는 이 표 지 를 통 해 사용 자 를 식별 할 수 있 습 니 다.마치 신분증 과 같 습 니 다.
2.침묵 로그 인 이란 무엇 인가?
일반적인 응용 에서 사용 자 는 폼 검증 을 통 해 로그 인 을 통 해 사용자 체 계 를 구축한다.이런 흔히 볼 수 있 는 로그 인 방식 은 로그 인 페이지 폼 을 통 해 로그 인 을 하 는 것 으로 사용자 에 게 감각 적 이다.
작은 프로그램 에서 위 챗 을 기반 으로 하기 때문에 위 챗 이 공식 적 으로 제공 하 는 API 능력 을 통 해 저 희 는 사용자 신분 표지(openid)를 감지 하지 못 하고 작은 프로그램 안의 사용자 체 계 를 신속하게 구축 하여 사용자 에 게 감지 되 지 않 기 때문에 프로그램 으로 이 자동 로그 인 과정 을 완성 할 수 있 습 니 다.
2.1 로그 인 절차 순서
아래 그림 은 위 챗 공식 에서 추출 한 것 이다.

애플 릿 에서 wx.login()을 호출 하여 code 를 가 져 와 서버 에 업로드 합 니 다.

export async function doLogin() {
 if (isLogin) return false
 isLogin = true
 removeCache('token')
 const { code } = await wxp.login()
 const data = await login({ code })
 setCache('token', data.data.token)
 isLogin = false
 return true
}

     code，  auth.code2Session    openid
const getOpenid = async function (appid, secret, code) {
    const resData = await axios.get('https://api.weixin.qq.com/sns/jscode2session?appid=' + appid + '&secret=' + secret + '&js_code=' + code + '&grant_type=authorization_code');
    return resData.data;
}

총 결 절차:

애플 릿 에서 wx.login()을 호출 하여 code 를 가 져 오고 서버 에 업로드 합 니 다

서버 는 코드 에 따라 위 챗 을 호출 합 니 다auth.code2Session인 터 페 이 스 를 openid 로 바 꿉 니 다

4.567917.백 스테이지 서버 는 openid 에 따라 사용자 정의 token 을 생 성하 여 전단 으로 돌아 가 저장 하고 후속 업무 논 리 는 token 으로 사용자 의 신분 을 식별 합 니 다3.사용자 정의 로그 인 상 태 를 어떻게 유지 합 니까?
공식 적 인 처리 방식 을 살 펴 보 자.

wx.checkSession({
  success () {
    //session_key    ，            
  },
  fail () {
    // session_key     ，          
    wx.login() //    
  }
})

그림 에서 우 리 는 로그 인 상 태 를 진정 으로 결정 하 는 것 이 위 챗 의 checkSession 인터페이스 라 는 것 을 알 수 있다.따라서 사용자 로그 인 상태 가 유효한 지 확인 할 때마다 checkSession 인 터 페 이 스 를 호출 합 니 다.만약 sessionkey 가 효력 을 잃 고 로그 인 절 차 를 시작 합 니 다.
4.전체 프로 세 스 에 침묵 로그 인
4.1app.onLaunch 에서 로그 인 시작
대부분의 인터페이스 호출 은 token 인증 이 필요 하기 때문에 애플 릿 이 시작 하 는 주기 함수 app.onLaunch 에서 침묵 로그 인 을 하 는 것 이 가장 적합 합 니 다.

4.2 처리 애플 릿 은 비동기 차단 을 지원 하지 않 습 니 다.
애플 릿 의 시작 프로 세 스 에서 페이지 급 과 구성 요소 급 의 수명 주기 함수 가 비동기 차단 을 지원 하지 않 습 니 다.따라서 app.onLaunch 에서 시 작 된 wx.login 이 성공 하지 못 했 을 때 페이지 급 수명 주기 함수 가 서버 에 요청 되 었 습 니 다.우리 의 인터페이스 디자인 은 대부분 검증 이 필요 하기 때문에 이때 로그 인 이 성공 하지 못 했 고 token 도 정확하게 돌아 오지 않 았 기 때문에 페이지 급 수명 주기 에 시 작 된 데이터 획득 인 터 페 이 스 는 틀림없이 잘못 보 고 될 것 이다(예 를 들 어 401 을 되 돌려 주 었 다).
4.2.1 조잡 한 방안
반전 함수 방식 을 채택 하 다

//app.js
this.globalData.wxp.showLoading({
        title: '   ...'
      });
      await login();
      this.globalData.hasLogin = true;
      if (this.checkLoginReadyCallback) {
        this.checkLoginReadyCallback();
      }
      this.globalData.wxp.hideLoading();
      
        
async onLoad() {
    if (app.globalData.hasLogin) {
    //             
      this.getUserInfo();
      this.getEvent();
    } else {
    //          ， app.js          
      app.checkLoginReadyCallback = async () => {
        this.getUserInfo();
        this.getEvent();
      };
    }
  },

장점:심 플 하고 난폭 함
단점:코드 구조 차이;여러 페이지 가 시작 페이지 라면 여러 페이지 가 리 셋 함 수 를 정의 해 야 합 니 다(애플 릿 onShare 모드 를 사용 했다 고 가정 합 니 다)
4.2.2 우아 한 방식
fly.js라 이브 러 리 를 통 해 요청 에 대한 잠 금 체 제 를 실현 합 니 다.프로 세 스:app.js 에서 로그 인 을 시작 하 는 동시에 페이지 에서 도 요청 합 니 다.요청 차단기 에서 요청 한 인터페이스 가 화이트 리스트(token 인증 이 필요 없 는 인터페이스)인터페이스 와 token 이 존재 하 는 지 판단 합 니 다.모두 false 라면 현재 요청 을 잠 그 고 요청 대기 열 에 들 어가 로그 인 절 차 를 실행 합 니 다.로그 인 프로 세 스 가 성공 하면 잠 금 해제 요청 대기 열 을 열 고 페이지 급 요청 작업 을 계속 시작 합 니 다.다음 요청 차단기 의 코드 입 니 다:

//    
fly.interceptors.request.use(async (request) => {
	//  token            
	if (
		!getCache('token') &&
		!whiteList.some((item) => request.url.startsWith(item))
	) {
		fly.lock()
		//         unlock
		await doLogin()
		fly.unlock() //   ，             
	}

	if (getCache('token') && !fly.config.headers['Authorization']) {
		request.headers['Authorization'] = getCache('token')
	}
	request.headers['Content-Type'] = 'application/x-www-form-urlencoded'

	return request
})

물론 사용자 정의 로그 인 상태 도 만 료 될 수 있 습 니 다.응답 차단기 에서 오 류 를 포착 하여 처리 할 수 있 습 니 다.401 token 만 료 코드 가 감지 되 었 을 때 요청 대기 열 뒤의 요청 을 모두 잠 그 고 401 사용자 정의 로그 인 상태 가 만 료 되 는 것 을 방지 한 다음 에 로그 인 을 시작 하고 로그 인 에 성공 한 후에 잠 금 해제 행 위 를 해 야 합 니 다.후속 요청 대기 열 을 실행 하고 token 이 만 료 되 어 서버 에 거 부 된 인 터 페 이 스 를 다시 실행 합 니 다.그렇지 않 으 면 요청 이 실패 할 수 있 습 니 다.(침묵 로그 인 은 사용자 가 감지 하지 못 하기 때문에 갑자기 인증 정보 가 만 료 되면 사용자 가 이상 하 게 느 낄 수 있 습 니 다.따라서 사용자 가 다시 클릭 하거나 다른 행동 으로 시작 하 는 것 이 아니 라 이번 요청 을 다시 실행 해 야 합 니 다):

//     
fly.interceptors.response.use(
	(response) => {
		//       data    
		return response.data
	},
	async (err) => {
		if (err.status === 401) {
			//401  ，              401
			fly.lock()
			removeCache('token')
			//         unlock
			const isLoginSuccess = await doLogin()
			if (isLoginSuccess) {
				fly.unlock()
			}
                        //       token           
			return fly.request(err.request)
		}
	}
)

요청 이 동시 다발 일 수 있 기 때문에 로그 인 이 여러 번 실행 되 는 것 을 방지 하기 위해 doLogin 함수 에 대해 작은 개 조 를 했 습 니 다.

export async function doLogin() {
        //           
	if (isLogin) return false
	isLogin = true
        //        ，        
	removeCache('token')
	const { code } = await wxp.login()
	const data = await login({ code })
	setCache('token', data.data.token)
	isLogin = false
	return true
}

4.3 전체 흐름 도

5.마지막 에 쓴다
세부 적 인 독자 들 은 api 요청 에 최대 요청 수량 을 설정 하지 않 았 음 을 알 수 있 습 니 다.(위 챗 애플 릿 은 최대 5 개의 api 를 동시에 지원 합 니 다)이 점 은 보충 해 야 합 니 다.전체적으로 보면 작 가 는 실현 방식 에 있어 진보 적 인 공간 이 있다 고 생각한다.작가 의 능력 이 유한 하고 공부 하면 서 토론 하 는 것 이다!
위 챗 애플 릿 침묵 로그 인 및 사용자 정의 로그 인 상태 유지 에 관 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 위 챗 애플 릿 침묵 로그 인 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 찾 아 보 세 요.앞으로 많은 응원 바 랍 니 다!