使用官方的PHP版demo解密，调用接口后返回错误码-41003，并未成功解密出想要的信息，请问有遇到的吗？如何来解决

使用社区的过程中，在社区的功能、奖励措施、处理问题等方面，你遇到过哪些体验很好的情况，又遭遇到过哪些不太友好的情况？ 面对这些，你的感受是怎样的？又有哪些建议？快来告诉我们吧！ 

之前开发完上线之后，都是正常的。后来，不知是不是ios系统更新了，cover-view上设置的position:fixed失效了,导致和屏幕一起滚动了 之前好好的，明明什么代码都没改，ios就突然不行了，求个说法 (由于页面中有map组件，所以用的是cover-view组件）

各位小程序开发者： 小程序服务类目现增加“社交红包”，开发者可在小程序管理后台中添加。基于保护用户资金安全的考虑，在申请社交红包类目的红包小程序时，开发者须知悉以下情况： 1. 所有提供含有微信用户充值红包功能的小程序，必须选择“社交红包”类目，并提交《增值电信业务经营许可证》； 2. 社交红包小程序的商户号需满足资金监管要求，微信用户支付给商户的资金在提现等功能将受该类目的限制和影响； 3. 社交红包小程序的使用流程、支付与提现功能、用户体验与交互等，需与微信红包功能保持一致，确保用户可实时提现；社交红包小程序暂不支持 UGC 类内容 (用户产生内容，如用户自定义的文字、图片、语音等) 和红包广场功能，否则将在小程序上架审核时被拒绝； 4. 社交红包的类目在审核通过后，将无法删除，请开发者谨慎考虑此类目对非社交红包功能的资金提现所产生的影响。

小程序审核突然没通过，理由如下： [图片] 这个问题开发过程中自己确实遇到过，几率性的，一般第一次不行，第二次肯定可以了，但是不是一开始写小程序就有的，不知道什么时候开始就这样了，验证的逻辑都是按照官方的，从来没有改变过。然后上社区一搜，很多类似的问题，如下图所示。 [图片] 看了下这个问题，第一次验证签名如下： [图片] 小程序端通过wx.login成功后获取的code rawdata，这个我都是同一用户登录，前后信息没啥变化 通过1中的code，后端调用api获得的session data，其中openid肯定同一用户每次也都一样的，session_key如果过期，那么第一次和第二次理论应该是不一样的。（但实际情况前后两次是一致的，具体可参见下图） 小程序端获取到的用户的签名 后端通过session key校验出来的签名。 很明显，4和5不一致，校验失败。接下来是第二次交验： [图片] 还是同样的逻辑顺序。 小程序端通过wx.login成功后获取的code。很明显，code跟第一次是不一样的，另外根据官方文档描述，因为又重新调用了wx.login，会导致session_key过期。（这似乎说明code发生变化也是对的，因为按推测，seesionkey应该也发生了变化，否则怎么叫“被更新”）请看下图官方文档说明：[图片] rawdata，这个我都是同一用户登录，前后信息没啥变化 根据1中的官方描述，奇怪的现象就发生了，在后端根据新的code，获取的session data，很明显session key还是第一次是一样的，也就是说，我重新调用了wx.login, code是变了，但是session key却和第一次保持一致的。 小程序端获取到的用户的签名 后端通过session key校验出来的签名。因为用的是同样的rawdata，同样的session key，所以两次校验的结果是一样的，但是第二次4中，小程序端获取的签名是跟此次校验结果是一致的。 所以问题就来了，这问题到底出在什么地方？似乎官方文档描述的就有问题，还是我本身的逻辑顺序有问题？请官方指教，谢谢。

- 需求的场景描述（希望解决的问题） 能实现下面的能力，谢谢啦！！！ 能实现下面的能力，谢谢啦！！！ 能实现下面的能力，谢谢啦！！！ - 希望提供的能力 1、绑定过开放者平台的小程序wx.login()接口可以直接返回unionid。 原因：大部分开发者调用wx.getUserinfo()接口是为了获取unionid来实现多应用打通，如果wx.login()接口可以直接返回unionid的话，可以减少很大一部分直接弹窗授权的小程序，从而提高用户体验，大家都能互惠互利。 2、绑定过开放者平台的应用openid转unionid的接口能力 原因：开发者一开始没有绑定开发者平台，后来规模做大了，需要扩展应用了，这时候历史数据就比较麻烦了，因为没有保存unionid。 最直接的场景就是微信公众号和小程序数据打通，没有小程序的时候用户基本上都是在公众号的维护的，有了小程序就需要扩展打通，但问题来了，取关了公众号的用户数据就没有办法和小程序打通了，只能等用户再次关注才有机会获取unionid。既然这个unionid是用来打通应用之间数据用的为什么这么不人性化，或者还是设计的时候没有考虑到，希望能体谅一下开发者和新媒体运营商，减少他们的工作量，让他们有更多的时间了服务用户，而不是把时间浪费在和这些接口打架上。

以下言论已经在不同的帖子中分别说过了，但是还是觉得如鲠在喉、不吐不快，所以特意单独发一个帖子来吐槽一下最近微信升级给小程序带来的两个变化 1、web-view强制显示顶栏 小程序可以不显示顶栏可以说是小程序少有的几个有亮点的特性之一，开发者可以使用更多的屏幕空间来开发和设计，虽然还有一些不足（比如：不能每个页面单独设置是否需要顶栏），但是瑕不掩瑜，总体来说还是很不错的。这次升级直接就强制web-view必需显示顶栏。有用户提出web-view需要顶栏的时候我就担心官方会无脑一刀切，结果还是不幸猜中了。针对这个需求，有很多更合适的对应方法，比如开放单页面单独设置，比如给web-view加一个全局的单独设置，结果官方选了一个最愚蠢的处理方式：无脑一刀切强制显示。我一直认为升级应该以不影响现有效果，或者最起码短期内不影响为前提，官方这次是实实在在的在作恶。 2、ipad上可以横屏使用小程序 小程序的rpx特性可以说是小程序少有的几个有亮点的特性之一，不管什么条件下屏宽固定都是750rpx，这个就一举解决了困扰开发者的适配问题，虽然还有一些不足（比如：部分组件不支持使用rpx设置尺寸、部分接口返回的尺寸没有rpx），但是瑕不掩瑜，必需点赞。但是这次升级后ipad上可以横屏使用小程序，而且横屏下屏宽不在是固定的750rpx，可以说是把开发者一夜打回解放前。如果说web-view强制显示顶栏是在作恶，这个可能是属于准备不足吧，希望后续可以解决。目前还是有一个应对方法，在app.json中加入“resizable: false”强制禁止横屏使用。 另外以上两个变化在最新的（截至发帖前）开发者工具中并没有对应。 最后我想奉劝微信的技术部门，作恶也要有个限度，不要仗着自己能店大欺客就肆无忌惮，做人留一线，给自己积点德没什么坏处。还有，靓坤教导我们：做错就要认，挨打要立正。不要认为自己是腾讯大厂的，承认自己做错或者不会做是折了面子，把bug硬说成feature这种把戏一直玩就没意思了。 再补一个，我上周发了一bug贴，说ipad横屏宽度不是750rpx，结果官方的回复要我提供代码片段。呵呵，ipad横屏宽度是不是750rpx，自己作为官方心里没点数吗？

chooseLocation，能否可以传入一个指定的坐标？很多时候 选择位置是希望先查看之前的位置 或者在位置附近重新选择，而不是每次打开都是当前位置。 我也试着自己开发一个这个功能，但是遇到了两个问题 wx.chooseLocation默认打开的页面的确定按钮是在上面的，节省了一部分空间，我们目前做不到 也是比较重要的一点，我们无法实现附近的poi的功能，腾讯位置服务 http://lbs.qq.com/webservice_v1/guide-search.html 倒是有地点搜索功能，但是keyword是必须传的，而且不能传多个，那我们就必须要么检索酒店，要么检索加油站 ... 反正只能检索一种，不能像wx.chooseLocation一样 可以不用传keyword https://lbs.qq.com/tool/component-picker.html。 所以我放弃了。 现在就指望你们能给chooseLocation加一个传入指定坐标的功能。这个应该不难吧