微信<web-view>内嵌h5页面，ios机型window.location.replace无效，安卓正常，大佬们看看啊 [图片]

vue项目，第一次微信授权后浏览器多出一条历史记录，需要点击两次后退才能退回到上一页，大家都是如何处理的

微信网页授权要怎么同时拿到手机号？

刚发现微信公众号的网页授权多了一次跳转，地址如下 https://open.weixin.qq.com/connect/oauth2/authorize_reply 请问这个是新加的什么功能吗

手机微信端获取授权code的时候，微信服务器重点向了两次问题 这问题有人提过，不过后面不了了之，所以我再提一次 解决方案 加 &connect_redirect=1 即：https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE&connect_redirect=1#wechat_redirect   这种做法测试过，微信服务器确实是只重定向了一次，不过也有人说有些手机加了这参数还不行。那么问题来了，这个参数在微信官方的开发文档中并未提及，而且微信接口是有做正则判断的，顺序稍错就不能通过，但很明显，这么加是能通过的，说明微信这API是有这个参数的，但没写到文档上，我不知道是文档没及时更新还是其他什么原因。 Nginx配置，有人说是因为环境的问题，由于现在服务器大都使用nginx作为代理，导致微信服务器认为你的域名请求不一致，会回调两次，重定向你的服务器两次。但这种方式有人说他解决了，但并未给出具体如何解决的思路及方案，此方法我没试成功。 希望微信官方解答下，感谢！     

针对于公众号网页授权 https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/Wechat_webpage_authorization.html 中的 “第一步：用户同意授权，获取code”，JS-SDK 不提供支持获取用户 code 的能力吗

如何解决在Vue项目IOS微信端用localhost.href打开微信网页授权有两个历史记录问题？ 并且IOS网页内点击返回按钮，历史第一条记录出现页面元素丢失或空白问题。 [图片] [图片][图片][图片][图片]

微信网页授权，跳转https://open.weixin.qq.com/connect/oauth2/authorize获取code,code拼接到redirect_uri上，之后跳转redirect_uri 跳转redirect_uri是push 还是replace？目前测试发现是push导致返回时还是上一个页面

小程序迁移，AppId、AppSecret、openid都不会变，unionID会视情况而定： 1、如果只是单纯的小程序迁移，不涉及open帐号变化，unionID就不会变。但是有可能会因为主体改变而影响unionID的获取逻辑，请开发者根据实际情况调整UnionID的获取方式。 2、如果涉及到open帐号变化，unionID就会改变，因为unionID就是根据open帐号的信息直接计算出来的。

如题，我们公司有A,B两个开放平台账号，现在想把A账号下的APP迁移到B账号下去。可以实现吗？流程一样的吗？

已知迁移移动应用时openid、appSecret不变，unionid会变。 请问是否能提供类似服务号迁移中提供的openid转化接口https://kf.qq.com/faq/1901177NrqMr190117nqYJze.html，把已有用户的unionid整体转换为新的unionid，以避免让所有用户重新授权登录？ 如果必须让所有用户重新授权登录才能获取新的unionid，那用户如果未登录移动应用，而是先登录了公众号或小程序，就会生成一个新的账号，对用户影响会很大。 希望微信能够提供一个完整的迁移移动应用、小程序、公众号并能保留老用户账号的方案。

背景：当前开放平台老账户下有小程序、公众号、APP，需要都迁移到新的开放平台账号下，两个开放平台主体不一样。 问 1、迁移后，openID、unionID是否都会发生改变？ 2、如何迁移？迁移过程是否会影响线上使用？

您好。我们小程序有一个投票功能，为了防止投票接口恶意被刷，我们用了前后端md5（参数+约定key）, 加密方式。但是发现我们的小程序可能被反编译，通过我们后台日志分析，sign参数的加密方式完全正确。我们之所以认为他是恶意接口，是因为这个ip或者openid没有任何其他浏览日志，只有投票接口日志。 万般无奈之下，我们决定尝试用wx.login拿code当参数传进来。 每次投票不仅要传递sign签名参数和登陆时openid参数，还会传递code(用wx.login获取一个新的code)。服务端用code即时拿openid，并对比这个openid与传进来的openid参数是否一致。理论上，恶意刷投票接口的程序应该拿不到正确当code才对。但经过日志分析，我们升级此方案后，刷票行为大约停止了1天。然后又很快被破解。 1天后，又出现了，同ip或openid没有其他浏览日志，只有投票日志。并且投票日志中带的code参数也顺利换取了openid。 注1：我们小程序登陆之后的每个接口，都带了openid参数。所以能分析出某个openid的行为浏览日志。 注2：我们用了jwt。token字段是每个接口都有的。对方会批量注册很多账号，都是真实有效的微信号。会把我们的token和对应的openid保存起来。我们token的有效期确实也有点长。 注3：对方刷票不是说随便刷，就是一个openid肯定只能刷一票，但对方有很多openid。并且每个都是注册进来的，真实有效的。服务端有IP防刷，但对方基本上刷3，4票，换一个IP。 注4：也排出羊毛党刷单群这种，因为这种肯定有其他的浏览记录，不可能直接调投票接口。 注5: 我们后台通过行为日志肯定能分析出被刷票的作品，但不能随意取消作品，怕别人是恶意被刷。 注6: 就是不理解刷子是如何拿到正确的code。

从小程序打开app,如果app未被杀掉是可以拿到小程序的参数的，如果被杀掉拿不到参数