위 챗 공중 번호 사용자 와 사이트 사용자 의 연결 솔 루 션 분석
현재 많은 사이트 들 이 완전한 사용자 계 정 체 계 를 구축 했다.이 체 계 를 바탕 으로 다른 응용 을 하 는 사용자 의 확장 이 매우 편리 하 다.예 를 들 어 마이크로소프트 아 틀 룩 계 정 이 있 으 면 win 8 에 로그 인 할 수 있 고 마이크로소프트 메 일 에 로그 인 할 수 있 으 며 skype 에 로그 인 할 수 있다.마찬가지 로 하나의 애플 ID 는 애플 의 모든 서 비 스 를 누 릴 수 있다.이른바 하나의 계 정 은 곳곳에서 사용 된다.
기업 에 대해 제품 라인 은 보통 사이트,app,위 챗 공식 번호 등 이 있 을 수 있 습 니 다.제품 라인 별 계 정 체 계 를 통일 해 하나의 계 정 이 곳곳에서 사용 되 는 목 표를 달성 하 는 것 이 필요 하 다.사이트 와 app 은 같은 계 정 을 사용 합 니 다.불필요 한 작업 을 하지 않 아 도 됩 니 다.고객 은 사용자 이름 비밀번호 만 있 으 면 로그 인 할 수 있 습 니 다.위 챗 공식 번호 에 대해 위 챗 공식 플랫폼 을 바탕 으로 하 는 응용 이기 때문에 플랫폼 의 규칙 을 지 켜 야 하기 때문에 추가 적 인 작업 을 해 야 계 정 이 서로 통 하 는 목 표를 달성 할 수 있다.
다음은 위 챗 공식 번호 사용자 와 사이트 사용자 의 계 정 시스템 이 틈새 없 이 연결 되 는 방법 에 대해 논의 해 보 겠 습 니 다.
사용자 가 위 챗 공중 번 호 를 주목 하면 상호작용 이 있 을 수 있다.상호작용 과정 에서 사용자 의 신분 정보(사이트 에 대응 하 는 계 정 정보)를 얻어 야 할 수도 있다.예 를 들 어 공중 번호 에서 주문 을 내리 고 주문 서 를 조회 하 는 등 조작 이다.그러면 지금 문제 가 생 겼 습 니 다.같은 사용자 에 대해 우 리 는 어떻게 위 챗 공중 번호 사용자(openid)와 사이트 사용자(userid)간 의 대응 관 계 를 구축 합 니까?이 과정 을 우 리 는 귀속 이 라 고 부른다.
위 챗 계 정 귀속
토론 을 간소화 하기 위해 나 는 이런 두 장면 을 총 결 했다.
1.사용 자 는 이미 우리 의 사이트 사용자 로 등록 되 었 으 나 우리 의 위 챗 공중 번호 에 관심 이 없습니다.
2.사용자 가 등록 하지 않 았 지만 우리 의 위 챗 공식 번호 에 관심 이 있 습 니 다.
상기 두 가지 상황 에 대해 아래 에서 각각 토론 한다.
장면 1
사용 자 는 이미 우리 의 사이트 사용자 로 등록 되 었 으 나,아직 우리 의 위 챗 공식 번호 에 관심 이 없다.어떻게 사용자 가 공중 번호 에 관심 을 가지 도록 편리 하 게 하 는 동시에 사용자 와 위 챗 공중 번 호 를 한데 연결 할 수 있 습 니까?자 연 스 럽 게 QR 코드 라 는 입 구 를 생각 할 수 있 습 니 다.
최근 몇 년 동안 QR 코드 의 응용 은 특히 광범 위 하 다.위 챗 이 QR 코드 에 대한 홍보 와 응용 은 물 만난 고기,위 챗 QR 코드 결제,위 챗 QR 코드 로그 인,위 챗 QR 코드 명함 등 이 라 고 할 수 있다.QR 코드 는 이미 O2O 에서 온·오프라인 을 연결 하 는 중요 한 연결 고리 가 됐다 고 할 수 있다.망아지 형 도"QR 코드 는 온·오프라인 의 중요 한 입구"라 고 말 했다.
여기 서 사용자 가 사이트 에 먼저 로그 인 한 다음 에 적당 한 곳 에 귀속 입 구 를 제시 해 야 한다.예 를 들 어 개인 설정 에 있다.바 인 딩 프로 세 스 는 다음 과 같 습 니 다:
위 챗 계 정 바 인 딩 절차
여기에 위 챗 의 QR 코드 생 성 기능 이 필요 합 니 다http://mp.weixin.qq.com/wiki/18/28fc21e7ed87bec960651f0ce873ef8a.html
위 챗 QR 코드 에 대해 공식 문서 에서 이렇게 말 했다.
현재 임시 QR 코드 와 영구 QR 코드 등 2 가지 유형의 QR 코드 가 있 는데 전 자 는 만 료 시간 이 있 고 유효기간 은 30 일(2592000 초)이지 만 비교적 많은 수량 을 생 성 할 수 있다.후 자 는 만 료 시간 이 없고 수량 이 비교적 적다(현재 매개 변 수 는 1-100000,즉 10 만 개 만 지원).두 가지 QR 코드 는 각각 계 정 바 인 딩,사용자 출처 통계 등 장면 에 적용 된다.
분명히 우 리 는 임시 QR 코드 를 사용 하 는 것 이 비교적 적합 하 다.사용자 가 페이지 를 새로 고 칠 때마다 한 번 씩 생 성 할 수 있 습 니 다.
QR 코드 에 장면 값(sceneid)사용자 가 장면 값 이 있 는 QR 코드 를 스 캔 하면 위 챗 서버 는 장면 값 을 우리 자신의 서버 에 보 냅 니 다.우 리 는 장면 값 을 받 으 면 검증 과 바 인 딩 논 리 를 할 수 있 습 니 다.메모:QR 코드 를 만 들 려 면 인증 후의 서비스 번호 가 필요 합 니 다.
완전한 바 인 딩 프로 세 스 는 다음 과 같 아야 합 니 다.
① 사용자 가 홈 페이지 에 접속 하여'위 챗 계 정 연결'을 클릭 한다.
② 배경 에서 위 챗 인 터 페 이 스 를 사용 하여 QR 코드 링크 를 생 성하 여 전단 에 표시 하고 장면 값 A 와 사용자 의 대응 관 계 를 구축한다.
③ 사용자 가 QR 코드 를 스 캔 하고 위 챗 공식 번 호 를 클릭 합 니 다(관심 이 있 으 면 ④ 로 바로 이동).
④ 배경 에서 위 챗 서버 가 푸 시 하 는 장면 값 A 를 받 습 니 다.
⑤ 배경 은 장면 값 A 에 따라 해당 하 는 사용자 ID(② 에서 구 축 된 대응 관계 에 의존)를 조회 합 니 다.
⑥ 사용자 userid 와 위 챗 사용자 openid 의 대응 관 계 를 구축한다.
⑦ 사용자 의 위 챗 클 라 이언 트 에 게'바 인 딩 성공'이라는 힌트 를 보 냅 니 다.
⑨ 프론트 페이지 에 바 인 딩 이 완료 되 었 음 을 알 리 고 페이지 를 새로 고치 고 위 챗 계 정 정 정 보 를 되 돌려 줍 니 다.귀속 완료.
그 중에서 ② 에서'장면 값 A 와 사용자 간 의 대응 관계 구축'은 사용자 가 로그 인 했 기 때문에 사용자 가'위 챗 계 정 연결'을 클릭 할 때 저 희 는 배경 에서 임시 장면 값 A 와 사용자 ID 간 의 관 계 를 배정 할 수 있 습 니 다.사용자 수가 많 지 않 은 사이트 에 대해 서 는 phop 의 apc 를 직접 사용 하여 캐 시 를 하고 만 료 시간 을 설정 할 수 있 습 니 다(임시 QR 코드 만 료 시간 과 똑 같이 설정 하면 됩 니 다).이러한 대응 관 계 를 session 으로 저장 하지 마 십시오.④ 는 위 챗 의 푸 시 이벤트 이기 때문에 session 정 보 를 가지 고 있 지 않 으 며 redis 와 같은 캐 시 나 DB 를 사용 하여 저장 할 수 있 습 니 다.또 이곳 에 서 는 임시 QR 코드 를 사용 해 야 하 는데 수량 에 제한 이 없고 시간 제한 만 있 으 며 프런트 는 정시 에 리 셋 하면 된다.
⑨ 에서 http 에 푸 시 메커니즘 이 없 기 때문에 가장 쉬 운 방법 은 돌아 가면 서 조회 하 는 것 입 니 다.바 인 딩 이 완료 되 었 는 지,바 인 딩 이 완 료 된 후에 페이지 를 새로 고 치 는 것 입 니 다.
바 인 딩 을 완료 한 후에 사용자 가 우리 의 위 챗 공중 번호 와 상호작용 을 할 때 openid 에 따라 해당 하 는 userid 를 찾 을 수 있 습 니 다.즉,신분 식별 을 완성 할 수 있 습 니 다.앞서 언급 한 주문서 에 대해 서 는 주문 서 를 조회 할 수 있 습 니 다.
전체 바 인 딩 과정 이 복잡 하지 않 고 실현 하기에 도 큰 기술적 난이도 가 없 으 며 가장 관건 적 인 것 은 사고 이다.
상기 절 차 는 사용자 가 이미 웹 페이지 에 로그 인 한 것 이다.즉,이미 가입 한 사용자 라 는 것 이다.로그 인 하지 않 은 경우 에 도 로그 인 페이지 에 QR 코드 를 생 성하 여 사용자 가 위 챗 으로 쓸 수 있 도록 할 수 있 습 니 다.사용자 가 이미 등록 했다 면 자동 으로 로그 인하 여 사이트 계 정과 위 챗 계 정의 연결 을 완성 할 수 있 습 니 다.만약 에 사용자 가 등록 하지 않 으 면 홈 페이지 는 바 인 딩 계 정 페이지 로 넘 어가 고 사용자 가 메 일 비밀 번 호 를 입력 하면 신속하게 등록 하 는 동시에 사이트 계 정과 위 챗 사용자 의 바 인 딩 도 완성 합 니 다.기술 방안 을 실현 하 는 것 은 상술 한 것 과 유사 하 다.
장면 2
장면 2.사용자 에 게 조작 은 약간 복잡 하 다.왜냐하면 사용자 가 위 챗 클 라 이언 트 의 홈 페이지 에서 로그 인/등록 을 완성 해 야 하기 때문이다.따라서 등록 과정 이 너무 복잡 하고 번 거 로 우 면 사용 을 권장 하지 않 는 다.
흐름:
사용자 바 인 딩 계 정 절차
상기 바 인 딩 프로 세 스 는 등록 과정 을 통합 하여 비교적 복잡 해 보인다.실현 하기 도 어렵 지 않 습 니 다.저 희 는 안전성 에 관 한 문 제 를 중점적으로 주목 하 겠 습 니 다.바 인 딩 계 정 은 사용자 의 정보 안전 과 관련 되 기 때문에 두 가지 문 제 를 고려 합 니 다.
1.링크 가 위조 되 는 것 을 어떻게 방지 합 니까?
로그 인/등 록 된 링크 는 우리 자신의 서버 가 생 성 되 었 는 지 확인 해 야 하 며,다른 사람 은 위조 할 수 없습니다.위 챗 의 인증 서버 주소 의 유효성 을 참고 할 수 있 습 니 다:
http://mp.weixin.qq.com/wiki/17/2d4265491f12608cd170a95559800f2d.html 。
그래서 비교적 안전 한 로그 인 링크 는 다음 과 같 을 수 있 습 니 다.
http://api.hello1010.com/wechat/login.html?openid=x1&signature=x2×tamp=x3&nonce=x4&echostr&=x5
서명 한 코드 검사:
private function checkSignature()
{
$openid = $_GET["openid"];
$signature = $_GET["signature"];
$timestamp = $_GET["timestamp"];
$nonce = $_GET["nonce"];
$token = TOKEN;
$tmpArr = array($token, $timestamp, $nonce, $openid);
sort($tmpArr, SORT_STRING);
$tmpStr = implode( $tmpArr );
$tmpStr = sha1( $tmpStr );
if( $tmpStr == $signature ){
return true;
}else{
return false;
}
}
token 값 은 자신의 위 챗 공식 번호 배경 과 일치 할 수도 있 고 바 꿀 수도 있 습 니 다.안전 점 을 바 꾸 는 것 을 권장 합 니 다.2.openid 가 신뢰 할 수 있 는 지 어떻게 확보 합 니까?
이러한 장면 을 고려 하면 A 사용 자 는 로그 인 페이지 에 들 어가 서 로그 인 링크 를 브 라 우 저 에 복사 하고 openid 를 B 사용자 의 openid 로 바 꾸 고 A 사용자 의 계 정 비밀 번 호 를 사용 하여 로그 인 합 니 다.이렇게 하면 A 사용자 의 userid 와 B 사용자 의 openid 를 연결 시 키 는 것 은 분명 안전 하지 않다.
해결 방안 은 매우 많다.예 를 들 어 openid 에 암호 화 할 수 있 고 암호 화 방법 이 비밀 인 상황 에서 사용 자 는 암호 화 된 openid 를 위조 할 수 없다.openid 에 암호 화 되 지 않 으 려 면 링크 를 만 들 때 서버 에서 openid 와 서명 signature 의 대응 관 계 를 만 들 수 있 습 니 다.사용자 가 openid 를 변경 하면 검증 을 통과 할 수 없습니다.
클 라 이언 트 가 보 내 온 정 보 를 쉽게 믿 지 말 라 는 것 을 기억 하 세 요.
확장 응용
바 인 딩 을 완성 한 후에 우 리 는 간단 한 응용 을 할 수 있 습 니 다.예 를 들 어 회 사 는 오프라인 로드 쇼 행 사 를 개최 해 야 하 는데 이 행 사 는 신청 을 해 야 참가 할 수 있 고 출석 을 해 야 한다.
위 챗 으로 가능 한 O2O 의 전형 적 인 예 다.절 차 는 다음 과 같다.
오프라인 로드 쇼 출석 절차
그 중에서'귀속 사용자 서브 프로 세 스'는 장면 2 의 프로 세 스 이다.신청 의 상호작용 은 여기 서 더 이상 반복 되 지 않 고 모든 업무 가 다르다.
바 인 딩 이 완 료 된 사용자 에 게 그 가 행사 에 참가 할 때 해 야 할 일 은 바로 위 챗 을 통 해 신청 한 다음 에 QR 코드 를 스 캔 하여 서명 하 는 것 이다.체험 이 상당히 유창 하 다.
만약 어떤 문제 가 있다 면,나 와 교류 하 는 것 을 환영 합 니 다!
더 많은 PHP 관련 내용 에 관심 이 있 는 독자 들 은 본 사이트 의 주 제 를 볼 수 있다.
본 논문 에서 말 한 것 이 여러분 의 PHP 프로 그래 밍 에 도움 이 되 기 를 바 랍 니 다.