微信登录报错：redirect_uri域名与后台配置不一致，错误码10003

我们可以根据微信的开发者文档

创新互联凭借专业的设计团队扎实的技术支持、优质高效的服务意识和丰厚的资源优势，提供专业的网站策划、成都网站设计、成都做网站、网站优化、软件开发、网站改版等服务，在成都10年的网站建设设计经验，为成都成百上千家中小型企业策划设计了网站。

网页授权获取用户验证这一章来排除错误原因。

如果确定appid等参数值没有出错 ，那么很大可能就是你的微信公众号后台的 网页授权网址没有填写或者填写的不正确 。

1、在微信公众号请求用户网页授权之前，开发者需要先到公众平台官网中的开发者中心页配置授权回调域名。

2、授权回调域名配置规范为全域名，比如需要网页授权的域名为： ，

配置以后此域名下面的页面 、 都可以进行OAuth2.0鉴权。

但 、 、 无法进行OAuth2.0鉴权

pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; overflow-wrap: break-word;"

搞了半天，才发现原来网页授权网址必须和redirect_uri的全域名要一样。 比如 网页授权网址填的是 qq点抗 ， redirect_uri写 这样也会报错。 /pre

微信公众号配置网页授权域名怎么设置?

1、打开微信公众平台，输入账号密码登录后台。

2、点击【公众号设置】。

3、点击【功能设置】。



4、找到【网页授权域名】，点击旁边的【设置】。



5、在修改业务域名和JS接口域名时，已经上传过这个文件的话，那么请直接跳过这一步。如果还没上传的，直接点击文件下载，然后上传到服务器。

6、上传成功后，直接输入授权域名，点击【确认】即可。

微信OAuth2.0授权回调页面域名设置问题

当下的解决方案是引入一个新的非常简单的应用来作为微信授权的代理服务，可以这么做：  

1. 把公众号的网页授权接口域名设置成另外一个子域名，如proxy.your点抗 ；    

2. 然后把php_weixin_proxy里面的index.php部署到proxy.your点抗

php_weixin_proxy下的index.php是一个很简单的php文件，你可以直接查看源码了解它的实现方式。因为当前项目的环境，我采用php来完成这个代理服务实现，实际上，你完全可以用任意平台语言来完成类似的功能。

当其它业务需要发起微信授权时，将授权请求先发到proxy.your点抗 ，然后proxy.your点抗 会把这个请求转发到微信；  

当用户同意授权后，proxy.your点抗 会收到微信的授权回调，并把回调结果（code、state参数）原封不动地再返回给最开始发起授权的业务。

唯一的区别在于，在不使用proxy.your点抗 的时候，你从应用发起微信授权的链接应该是这样的：  

;redirect_uri=http%3A%2F%2Fpassport.your点抗 %2Fresponse_type=codescope=snsapi_loginstate=584bc87e11ff37492#wechat_redirect    

用了proxy.your点抗 之后，这个授权链接就应该是这样的：    

;redirect_uri=http%3A%2F%2Fpassport.your点抗 %2Flogin%2Fnotifyresponse_type=codescope=snsapi_basestate=584bc87e11ff37492device=pc

后面这个链接跟上面的比：  

1. 后面的链接中的host变成了proxy.your点抗 ，也就是代理的授权回调域名；    

2. 后面的多了一个device参数，这个是必要的。因为微信pc端跟移动端的授权地址是不一样的，而后面的链接是发送个proxy.your点抗 的，所以需要多加个参数告诉它在转发给授权申请给微信的时候，是用PC端还是移动端的授权地址。

1. 用户从我们的应用触发需要授权的操作，比如点击微信登录；    

2. 应用收到这种用户请求后，将用户重定向到微信提供的一个授权页面：    

或    

3. 用户通过微信扫码（PC端授权，上边左图）或者点击确认按钮（移动端授权，上边右图）告知微信，授权应用访问自己的微信账号信息；    

4. 微信收到用户的授权许可后，生成授权码，并把它作为参数回调至应用的某个页面；    

5. 应用的回调页面在接收到微信的回调请求后，拿到其中的授权码，并通过微信官方提供的access token api接口获取access token；    

6. 最后通过access token以及微信官方提供的另一个userinfo api接口就能获取到用户的微信账号信息。

为了实现这个过程，首先要为应用申请一个微信公众号，并将应用最终部署的域名设置到微信公众号设置里面的授权回调页面域名这个选项里面。微信官方对这个选项的说明如下：

关于网页授权回调域名的说明

1、在微信公众号请求用户网页授权之前，开发者需要先到公众平台官网中的“开发 - 接口权限 - 网页服务 - 网页帐号 - 网页授权获取用户基本信息”的配置选项中，修改授权回调域名。请注意，这里填写的是域名（是一个字符串），而不是URL，因此请勿加 http:// 等协议头；

2、授权回调域名配置规范为全域名，比如需要网页授权的域名为：，配置以后此域名下面的页面 、 都可以进行OAuth2.0鉴权。但 、 、 无法进行OAuth2.0鉴权

3、如果公众号登录授权给了第三方开发者来进行管理，则不必做任何设置，由第三方代替公众号实现网页授权即可

由此可见，这个规则极其严格。如果说我们的应用最终部署的时候只有一个域名，那么这种规则不会有什么问题；但是考虑到将来应用的复杂性，我们可能在应用设计之初就会对应用做拆分，然后不同的业务采用不同的二级域名来部署。比如一个带有交易的应用，你可能会把登录注册，交易管理和常规业务都独立出来，然后采用以下的方式来部署它们：  

部署常规业务；    

trade.your点抗 部署交易管理的业务；    

passport.your点抗 部署登录注册的业务；    

在这种模式下，如果集成微信登录和微信支付，前面说的授权回调页面域名的规则就会给应用带来问题。在这里：至少可以确认trade.your点抗 和passport.your点抗 都需要前面的介绍的用户微信授权，但是它们是两个不同的子域名，而且我们只有一个公众号；根据授权回调页面域名的原则，它只能用一个域名，并且只有回调地址的域名与该设置完全相同，才能成功发起微信授权，否则就会提示rediret_uri参数错误或者引发无法回调的问题。

那么这种情况该如何处理？

当下的解决方案是引入一个新的非常简单的应用来作为微信授权的代理服务，可以这么做：  

1. 把公众号的网页授权接口域名设置成另外一个子域名，如proxy.your点抗 ；    

2. 然后把php_weixin_proxy里面的index.php部署到proxy.your点抗

php_weixin_proxy下的index.php是一个很简单的php文件，你可以直接查看源码了解它的实现方式。因为当前项目的环境，我采用php来完成这个代理服务实现，实际上，你完全可以用任意平台语言来完成类似的功能。

当其它业务需要发起微信授权时，将授权请求先发到proxy.your点抗 ，然后proxy.your点抗 会把这个请求转发到微信；  

当用户同意授权后，proxy.your点抗 会收到微信的授权回调，并把回调结果（code、state参数）原封不动地再返回给最开始发起授权的业务。

唯一的区别在于，在不使用proxy.your点抗 的时候，你从应用发起微信授权的链接应该是这样的：  

;redirect_uri=http%3A%2F%2Fpassport.your点抗 %2Fresponse_type=codescope=snsapi_loginstate=584bc87e11ff37492#wechat_redirect    

用了proxy.your点抗 之后，这个授权链接就应该是这样的：    

;redirect_uri=http%3A%2F%2Fpassport.your点抗 %2Flogin%2Fnotifyresponse_type=codescope=snsapi_basestate=584bc87e11ff37492device=pc

后面这个链接跟上面的比：  

1. 后面的链接中的host变成了proxy.your点抗 ，也就是代理的授权回调域名；    

2. 后面的多了一个device参数，这个是必要的。因为微信pc端跟移动端的授权地址是不一样的，而后面的链接是发送个proxy.your点抗 的，所以需要多加个参数告诉它在转发给授权申请给微信的时候，是用PC端还是移动端的授权地址。

整体方案思路：

小结：

这个方案我测试过，是行的通的。虽然说引入了代理服务，增加了一次重定向操作，不过由于这个授权请求并不是所有请求都需要，所以实际上也不会对用户体验产生多大的影响，但是从架构上来说，它的好处很明显，能够配合着应用的拆分逻辑，集成同一个公众号的登录及支付功能，不必为每个子应用都单独申请一个公众号来开发了（这种方式从业务上来说也不合理，一个公司哪需要运营那么多公众号）。

当前文章：公众号授权回调域名怎么填 公众号授权域名是干嘛的
本文网址：http://csdahua.cn/article/ddshgig.html