189 8069 5689
七台河网站制作公司哪家好，找成都创新互联！从网页设计、网站建设、微信开发、APP开发、响应式网站建设等网站项目制作，到程序开发，运营维护。成都创新互联从2013年开始到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选成都创新互联。
就是在登录回调的网址里面加一个网页，在这个网页里再判断做相应的跳转
不行吧，一次只能绑定一个域名，可以用一绑定一个域名然后获取code之后再跳转到另一个域名上同时发送code
如果为二级域名可以解决可以直接填写为xx和域名b 均可以使用，如果为两个域名的话就没办法解决了。
不行吧，一次只能绑定一个域名，可以用一绑定一个域名然后获取code之后再跳转到另一个域名上同时发送code
填写你第三方平台的域名即可~西里奥布~
登录微信公众号平台，在右上角，点击那个头像 然后就可以进入个人设置，个人设置里面第三个就是设置回调域名，，这上面是一个进去地方，还有一个地方，左下角那个开发者选项，里面就可以看到对这个平台有什么权限，在里面也有一个 回调域名，这两个是连接到同一个地方
登录微信公众号，在我的服务里找网页授权，点击进入修改。
1.在公众平台网站根本找不到如图中的”我的服务页“这一个左侧菜单。
2.虽然”我的服务“这个页面没有了，但是授权回调域名得设置这个功能还在，开发者可以在左侧的”开发者中心“配置，点开后最后有如图界面，红框中后面的”修改“点击后即可配置，目前为止腾讯的微信公众平台开发文档尚未更新。
你说的是授权的具体步骤！ 1. 用户关注公众号。
2. 公众号提供用户请求授权页面URL。
3. 用户点击授权页面URL，将向服务器发起请求 4. 服务器询问用户是否同意授权给微信公众账号(scope为snsapi_base时无此步骤) 5. 用户同意(scope为snsapi_base时无此步骤) 6. 服务器将CODE通过回调传给微信公众账号 7. 微信公众账号获得code 8. 微信公众账号通过code向服务器请求Access Token 9. 服务器返回Access Token和OpenID给微信公众账号 10. 微信公众账号通过Access Token向服务器请求用户信息(scope为snsapi_base时无此步骤) 11. 服务器将用户信息回送给微信公众账号(scope为snsapi_base时无此步骤) 注：网页授权scope分为两种：1.snsapi_base静默授权，用户无感知，只能获取到用户的openid；2.snsapi_userinfo用户授权，能获取到用户头像等信息，需要用户确认授权操作。
当下的解决方案是引入一个新的非常简单的应用来作为微信授权的代理服务，可以这么做： 1. 把公众号的网页授权接口域名设置成另外一个子域名，如proxy.your.com； 2. 然后把php_weixin_proxy里面的index.php部署到proxy.your.comphp_weixin_proxy下的index.php是一个很简单的php文件，你可以直接查看源码了解它的实现方式。因为当前项目的环境，我采用php来完成这个代理服务实现，实际上，你完全可以用任意平台语言来完成类似的功能。当其它业务需要发起微信授权时，将授权请求先发到proxy.your.com，然后proxy.your.com会把这个请求转发到微信； 当用户同意授权后，proxy.your.com会收到微信的授权回调，并把回调结果（code、state参数）原封不动地再返回给最开始发起授权的业务。唯一的区别在于，在不使用proxy.your.com的时候，你从应用发起微信授权的链接应该是这样的： https://open.weixin.qq.com/connect/qrconnect?appid=xxxxx&redirect_uri=http%3a%2f%2fpassport.your.com%2f&response_type=code&scope=snsapi_login&state=584bc87e11ff37492#wechat_redirect用了proxy.your.com之后，这个授权链接就应该是这样的： http://proxy.your.com/?appid=xxxxx&redirect_uri=http%3a%2f%2fpassport.your.com%2flogin%2fnotify&response_type=code&scope=snsapi_base&state=584bc87e11ff37492&device=pc后面这个链接跟上面的比： 1. 后面的链接中的host变成了proxy.your.com，也就是代理的授权回调域名； 2. 后面的多了一个device参数，这个是必要的。因为微信pc端跟移动端的授权地址是不一样的，而后面的链接是发送个proxy.your.com的，所以需要多加个参数告诉它在转发给授权申请给微信的时候，是用pc端还是移动端的授权地址。
1. 用户从我们的应用触发需要授权的操作，比如点击微信登录； 2. 应用收到这种用户请求后，将用户重定向到微信提供的一个授权页面： 或3. 用户通过微信扫码（pc端授权，上边左图）或者点击确认按钮（移动端授权，上边右图）告知微信，授权应用访问自己的微信账号信息； 4. 微信收到用户的授权许可后，生成授权码，并把它作为参数回调至应用的某个页面； 5. 应用的回调页面在接收到微信的回调请求后，拿到其中的授权码，并通过微信官方提供的access token api接口获取access token； 6. 最后通过access token以及微信官方提供的另一个userinfo api接口就能获取到用户的微信账号信息。为了实现这个过程，首先要为应用申请一个微信公众号，并将应用最终部署的域名设置到微信公众号设置里面的授权回调页面域名这个选项里面。微信官方对这个选项的说明如下：关于网页授权回调域名的说明1、在微信公众号请求用户网页授权之前，开发者需要先到公众平台官网中的“开发 - 接口权限 - 网页服务 - 网页帐号 - 网页授权获取用户基本信息”的配置选项中，修改授权回调域名。请注意，这里填写的是域名（是一个字符串），而不是url，因此请勿加 http:// 等协议头；
2、授权回调域名配置规范为全域名，比如需要网页授权的域名为：www.qq.com，配置以后此域名下面的页面http://www.qq.com/music.html 、 http://www.qq.com/login.html 都可以进行oauth2.0鉴权。但http://pay.qq.com 、 http://music.qq.com 、 http://qq.com无法进行oauth2.0鉴权3、如果公众号登录授权给了第三方开发者来进行管理，则不必做任何设置，由第三方代替公众号实现网页授权即可由此可见，这个规则极其严格。如果说我们的应用最终部署的时候只有一个域名，那么这种规则不会有什么问题；但是考虑到将来应用的复杂性，我们可能在应用设计之初就会对应用做拆分，然后不同的业务采用不同的二级域名来部署。比如一个带有交易的应用，你可能会把登录注册，交易管理和常规业务都独立出来，然后采用以下的方式来部署它们： www.your.com 部署常规业务； trade.your.com 部署交易管理的业务； passport.your.com 部署登录注册的业务； 在这种模式下，如果集成微信登录和微信支付，前面说的授权回调页面域名的规则就会给应用带来问题。在这里：至少可以确认trade.your.com和passport.your.com都需要前面的介绍的用户微信授权，但是它们是两个不同的子域名，而且我们只有一个公众号；根据授权回调页面域名的原则，它只能用一个域名，并且只有回调地址的域名与该设置完全相同，才能成功发起微信授权，否则就会提示rediret_uri参数错误或者引发无法回调的问题。那么这种情况该如何处理？当下的解决方案是引入一个新的非常简单的应用来作为微信授权的代理服务，可以这么做： 1. 把公众号的网页授权接口域名设置成另外一个子域名，如proxy.your.com； 2. 然后把php_weixin_proxy里面的index.php部署到proxy.your.comphp_weixin_proxy下的index.php是一个很简单的php文件，你可以直接查看源码了解它的实现方式。因为当前项目的环境，我采用php来完成这个代理服务实现，实际上，你完全可以用任意平台语言来完成类似的功能。当其它业务需要发起微信授权时，将授权请求先发到proxy.your.com，然后proxy.your.com会把这个请求转发到微信； 当用户同意授权后，proxy.your.com会收到微信的授权回调，并把回调结果（code、state参数）原封不动地再返回给最开始发起授权的业务。唯一的区别在于，在不使用proxy.your.com的时候，你从应用发起微信授权的链接应该是这样的： https://open.weixin.qq.com/connect/qrconnect?appid=xxxxx&redirect_uri=http%3a%2f%2fpassport.your.com%2f&response_type=code&scope=snsapi_login&state=584bc87e11ff37492#wechat_redirect用了proxy.your.com之后，这个授权链接就应该是这样的： http://proxy.your.com/?appid=xxxxx&redirect_uri=http%3a%2f%2fpassport.your.com%2flogin%2fnotify&response_type=code&scope=snsapi_base&state=584bc87e11ff37492&device=pc后面这个链接跟上面的比： 1. 后面的链接中的host变成了proxy.your.com，也就是代理的授权回调域名； 2. 后面的多了一个device参数，这个是必要的。因为微信pc端跟移动端的授权地址是不一样的，而后面的链接是发送个proxy.your.com的，所以需要多加个参数告诉它在转发给授权申请给微信的时候，是用pc端还是移动端的授权地址。整体方案思路：小结：这个方案我测试过，是行的通的。虽然说引入了代理服务，增加了一次重定向操作，不过由于这个授权请求并不是所有请求都需要，所以实际上也不会对用户体验产生多大的影响，但是从架构上来说，它的好处很明显，能够配合着应用的拆分逻辑，集成同一个公众号的登录及支付功能，不必为每个子应用都单独申请一个公众号来开发了（这种方式从业务上来说也不合理，一个公司哪需要运营那么多公众号）。