WeChat OAuth2.0 인증 콜백 페이지에서 도메인 이름 설정 문제를 해결하는 방법은 무엇입니까?

현재 해결책은 WeChat에서 승인한 프록시 서비스로 새롭고 매우 간단한 애플리케이션을 도입하는 것입니다.

1. 웹 인증 인터페이스 이를 proxy.your.com과 같은 다른 하위 도메인 이름으로 설정합니다.

2. 그런 다음 php_weixin_proxy의 index.php를 proxy.your.com 아래의 인덱스에 배포합니다. >php_weixin_proxy.php는 매우 간단한 PHP 파일이므로 소스 코드를 직접 보고 구현 방법을 이해할 수 있습니다. 현재 프로젝트 환경으로 인해 PHP를 사용하여 이 프록시 서비스 구현을 완료했습니다. 실제로 모든 플랫폼 언어를 사용하여 유사한 기능을 완료할 수 있습니다.

다른 기업이 WeChat 승인을 시작해야 하는 경우 승인 요청이 먼저 Proxy.your.com으로 전송된 다음 Proxy.your.com이 요청을 WeChat으로 전달합니다. p> 사용자가 승인에 동의하면 Proxy.your.com은 WeChat으로부터 승인 콜백을 수신하고 처음에 승인을 시작한 기업에 콜백 결과(코드, 상태 매개변수)를 그대로 반환합니다.

유일한 차이점은 Proxy.your.com을 사용하지 않는 경우 애플리케이션에서 WeChat 인증을 시작하는 데 사용하는 링크가 다음과 같아야 한다는 것입니다.

/connect/qrconnect? appid =xxxxxxamp;redirect_uri=2Famp;response_type=codeamp;scope=snsapi_loginamp;state=584bc87e11ff37492#wechat_redirect

proxy.your.com을 사용한 후 인증 링크는 다음과 같습니다.

/?appid=xxxxxamp;redirect_uri=2Flogin2Fnotifyamp;response_type=codeamp;scope=snsapi_baseamp;state=584bc87e11ff37492amp;device=pc

위 링크와 비교:

1. 다음 링크의 호스트는 프록시의 인증 콜백 도메인 이름인 proxy.your.com이 됩니다.

2. 다음 링크에는 필요한 추가 장치 매개변수가 있습니다. 위챗 PC와 모바일의 인증주소가 다르고, 다음 링크가 Proxy.your.com으로 전송되기 때문에 위챗에 인증신청을 전달할 때 PC를 사용할지, 위챗을 사용할지 알려주는 추가 매개변수를 추가해야 합니다. . 모바일 단말기의 승인된 주소입니다.

1. 사용자는 로그인을 위해 WeChat을 클릭하는 등 애플리케이션에서 승인이 필요한 작업을 트리거합니다.

2. 사용자가 WeChat 제공업체에 인증 페이지:

또는

3. 사용자가 WeChat에서 QR 코드를 스캔하거나(PC 인증, 왼쪽 그림 위) 확인 버튼을 클릭합니다(모바일 인증). , 위 오른쪽 그림) WeChat이 애플리케이션이 자신의 WeChat 계정 정보에 액세스하도록 승인했음을 알리기 위해

4. 사용자의 승인을 받은 후 WeChat은 승인 코드를 생성하고 이를 애플리케이션의 특정 페이지로 다시 호출합니다. 매개변수로

5. 애플리케이션의 콜백 페이지는 WeChat에서 공식적으로 제공하는 액세스 토큰 API 인터페이스를 통해 인증 코드를 받고 액세스 토큰을 얻습니다. p>6. 마지막으로 Access 토큰을 전달하고 WeChat에서 공식적으로 제공하는 다른 userinfo API 인터페이스를 통해 사용자의 WeChat 계정 정보를 얻을 수 있습니다.

이 프로세스를 구현하려면 먼저 애플리케이션에 대한 WeChat 공개 계정을 신청하고 애플리케이션의 최종 배포 도메인 이름을 WeChat의 인증 콜백 페이지 도메인 이름 옵션에 설정해야 합니다. 공개 계정 설정. 이 옵션에 대한 WeChat의 공식 설명은 다음과 같습니다.

웹페이지 승인 콜백 도메인 이름에 대한 지침

1. WeChat 공식 계정이 사용자 웹페이지 승인을 요청하기 전에 개발자는 퍼블릭 플랫폼 공식 홈페이지 먼저 "개발 - 인터페이스 권한 - 웹 서비스 - 웹 계정 - 사용자 기본 정보 획득을 위한 웹 인증" 구성 옵션에서 인증 콜백 도메인 이름을 수정하세요. 여기에는 URL이 아닌 도메인 이름(문자열)이 입력되므로 추가하지 마세요. 구성 후에는 이 도메인 이름 아래의 /music.html 및 /login.html 페이지가 OAuth2로 인증될 수 있습니다. .0. 단, OAuth2.0 인증은 불가능합니다.

3. 공식 계정 로그인 권한을 제3자 개발자에게 부여한 경우 별도의 설정을 할 필요가 없습니다. 그러나

이 규칙은 매우 엄격하다는 것을 알 수 있습니다. 애플리케이션이 최종적으로 배포될 때 도메인 이름이 하나만 있는 경우 이 규칙에는 문제가 없지만 향후 애플리케이션의 복잡성을 고려하여 애플리케이션 설계 초기에 애플리케이션을 분할한 다음 다른 비즈니스를 사용할 수 있습니다. 서로 다른 2차 도메인 이름을 사용하여 배포됩니다. 예를 들어, 트랜잭션이 있는 애플리케이션의 경우 로그인 등록, 트랜잭션 관리 및 일반 비즈니스를 분리한 후 다음과 같은 방식으로 배포할 수 있습니다.

www.your.com은 일반 비즈니스를 배포합니다. >

trade.your.com은 거래 관리 사업을 전개합니다.

passport.your.com은 로그인 등록 사업을 전개합니다.

이 모드에서는 WeChat 로그인과 앞서 언급한 콜백 페이지 도메인 이름 승인 규칙인 WeChat 결제는 애플리케이션에 문제를 일으킬 수 있습니다. 여기서는 적어도 trade.your.com과 Passport.your.com 모두 앞서 소개한 사용자 WeChat 인증이 필요하다는 것을 확인할 수 있지만 두 도메인은 서로 다른 하위 도메인이며 도메인 이름에 따라 공식 계정은 하나만 있습니다. 인증 콜백 페이지 원칙적으로 하나의 도메인 이름만 사용할 수 있으며 콜백 주소의 도메인 이름이 이 설정과 정확히 일치하는 경우에만 WeChat 인증이 성공적으로 시작될 수 있습니다. 그렇지 않으면 rediret_uri 매개변수가 있다는 메시지가 표시됩니다. 정확하지 않거나 다시 전화할 수 없는 문제가 발생합니다.

그렇다면 이런 상황은 어떻게 대처해야 할까요?

현재 해결책은 WeChat에서 승인한 프록시 서비스로 새롭고 매우 간단한 애플리케이션을 도입하는 것입니다.

1. 웹 인증 인터페이스 이를 proxy.your.com과 같은 다른 하위 도메인 이름으로 설정합니다.

2. 그런 다음 php_weixin_proxy의 index.php를 proxy.your.com 아래의 인덱스에 배포합니다. >php_weixin_proxy.php는 매우 간단한 PHP 파일이므로 소스 코드를 직접 보고 구현 방법을 이해할 수 있습니다. 현재 프로젝트 환경으로 인해 저는 PHP를 사용하여 이 프록시 서비스 구현을 완료합니다. 실제로 모든 플랫폼 언어를 사용하여 유사한 기능을 완료할 수 있습니다.

다른 기업이 WeChat 승인을 시작해야 하는 경우 승인 요청이 먼저 Proxy.your.com으로 전송된 다음 Proxy.your.com이 요청을 WeChat으로 전달합니다. p> 사용자가 승인에 동의하면 Proxy.your.com은 WeChat으로부터 승인 콜백을 수신하고 처음에 승인을 시작한 기업에 콜백 결과(코드, 상태 매개변수)를 그대로 반환합니다.

유일한 차이점은 Proxy.your.com을 사용하지 않는 경우 애플리케이션에서 WeChat 인증을 시작하는 데 사용하는 링크가 다음과 같아야 한다는 것입니다.

/connect/qrconnect? appid =xxxxxxamp;redirect_uri=2Famp;response_type=codeamp;scope=snsapi_loginamp;state=584bc87e11ff37492#wechat_redirect

proxy.your.com을 사용한 후 인증 링크는 다음과 같습니다.

/?appid=xxxxxamp;redirect_uri=2Flogin2Fnotifyamp;scope=snsapi_baseamp;state=584bc87e11ff37492amp;device=pc

다음 링크의 호스트는 프록시의 인증 콜백 도메인 이름인 proxy.your.com이 됩니다.

2. 다음 링크에는 필요한 추가 장치 매개변수가 있습니다. 위챗 PC와 모바일의 인증주소가 다르고 다음 링크가 Proxy.your.com으로 전송되기 때문에 위챗에 인증신청을 전달할 때 PC를 사용할지, 위챗을 사용할지 알려주는 추가 매개변수를 추가해야 합니다. . 모바일 단말기의 인증된 주소입니다.

전체 계획 아이디어:

요약:

이 계획을 테스트해 본 결과 효과가 있었습니다. 프록시 서비스가 도입되고 리디렉션 작업이 추가되지만 이 인증 요청이 모든 요청에 ​​필요한 것은 아니기 때문에 실제로 사용자 경험에 큰 영향을 미치지는 않지만 아키텍처 측면에서는 많은 이점이 있습니다. 애플리케이션의 분할 로직과 협력하여 동일한 공식 계정의 로그인 및 결제 기능을 통합할 수 있습니다. 개발을 위해 각 하위 애플리케이션마다 별도의 공식 계정을 신청할 필요는 없습니다. (이 방법은 기업에서 합리적이지 않습니다. 관점, 회사 그렇게 많은 공개 계정을 운영할 필요가 없습니다).