openid

我的爱好就是做计划，推翻计划，重新做计划，还有就是让别人监督我学习，监督我减肥，监督我改掉坏习惯。所以我准备为自己量身定做个小程序。小程序界面差不多布局好了，现在来实现小程序注册登陆自己的应用程。 一、小程序端： 1、.wxml <view class="container"> <button class="to-login" open-type="getUserInfo" bindtap="getUserInfo">登陆</button> </view> 2、.js：调用接口wx.login获取code，调用 wx.getUserInfo获取encryptedData和iv，将code，encryptedData和iv传到后台 getUserInfo: function () { //开启loading框 wx.showLoading({ title: '正在登录...', mask: true }); // 登录 wx.login({ success: function (res_login) { if (res_login.code) { //获取用户信息 wx.getUserInfo({ lang:'zh_CN', success: res => { console.log(res) wx.request({ url: 'http://192.168.1.101:8080

　　2020年4月之后，上架App Store得应用必须集成apple账号得登录。 　　近期博主刚好配合前端IOS集成apple登录，网上找了不少文章教程，发现基本都是网页集成登录或者是java代码，比较少纯后端net验证,期间也走了不少弯路，在这分享给大家实现思路和需要得注意事项。 　　文章开始前先说明一下此文环境为netcore3.1环境代码编写，IOS相关配置和文章请参考文末链接。 　　整体思路为：前端调用苹果接口获取到userID和authorizationCode,后端通过authorizationCode调用苹果接口验证，若检验成功会返回相关信息； 　　以下为apple官方接口文档说明： https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens 　　根据文档可知，调用授权码验证需要传递6个参数，其中3个必填 client_id ， client_secret 和 grant_type 。 　　 client_id 和 client_secret 为apple验证请求方是否合法， client_secret 得生成也本文得重点讲解。 　　 grant_type 我理解为操作方式，固定为验证授权码 authorization_code 和刷新token

写在前面 　　微软在更新.Net Core版本的时候，动作往往很大，使得每次更新版本的时候都得小心翼翼，坑实在是太多。往往是悄咪咪的移除了某项功能或者组件，或者不在支持XX方法，这就很花时间去找回需要的东西了，下面是个人在迁移.Net Core WebApi项目过程中遇到的问题汇总： 开始迁移 1. 修改*.csproj项目文件 <TargetFramework>netcoreapp2. 2 </TargetFramework> 修改为 <TargetFramework>netcoreapp3.1</TargetFramework> 2 修改Program public static void Main( string [] args) { CreateWebHostBuilder(args).Build().Run(); } public static IWebHostBuilder CreateWebHostBuilder( string [] args) => WebHost.CreateDefaultBuilder(args) .UseStartup <Startup>().ConfigureAppConfiguration((hostingContext, config) => { config.AddJsonFile($ " 你的json文件.json " ,

一、简介 Redis 它的英文全名是 Remote Dictionary Server ，翻译成中文叫做远程字典服务。是由C语言编写的，遵守BSD协议，完全开源免费的一款NoSql数据库。 BSD是" Berkeley Software Distribution"的缩写，意思是"伯克利软件发行版"。 BSD 开源协议 是一个给于使用者很大自由的协议。可以自由的使用，修改 源代码 ，也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件： 1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。 2． 如果 再发布 的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。 3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发 商业软件 发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。 二、redis特点 redis是一个高性能的key-value数据库 redis性能极高，一般情况下

一. 再谈认证和授权 （详见：https://www.cnblogs.com/yaopengfei/p/13141548.html） 1.认证 　　是验证身份的一种机制,比如用户名和密码登录,这就是一种认证机制,再比如现在比较流行jwt校验,通过用户名和密码访问接口,验证通过获取token的过程,也叫做认证。 2.授权 　　是确定你是否有权限访问系统的某些资源. 比如用户登录成功进入系统以后,要进行增加博客这个功能，系统要判断一下该用户是否有权限访问这个增加博客的功能，这个过程就叫做授权。 再比如某个客户端app携带token访问服务端某个api接口,这个时候服务端要校验一下该token是否有权限访问这个api接口，这个过程也是授权。 3.Core Mvc中认证和授权 　　在Core Mvc中,UseAuthentication()代表认证,UseAuthorization()代表授权, 需要注意的是这里的认证和授权 与 上述广义上的理解有点差异，在Core MVC中,UseAuthentication和UseAuthorization一般 是成对出现，且UseAuthentication认证需要写在上面，且需要在对应的api接口上加[Authorize]，代表该接口需要校验, 这样当该接口被请求的时候，才会走UseAuthentication中的认证逻辑。 (PS:

问题： I'm really trying to understand the difference between OpenID and OAuth? 我真的想了解OpenID和OAuth之间的区别吗？ Maybe they're two totally separate things? 也许他们是两个完全不同的东西？ 解决方案： 参考一： https://stackoom.com/question/4Yml/OpenID和OAuth有什么区别 参考二： https://oldbug.net/q/4Yml/What-s-the-difference-between-OpenID-and-OAuth 来源： oschina 链接： https://my.oschina.net/u/4438370/blog/4318166

使用slf4j 使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。 实现方式统一使用: Logback框架 打日志的正确方式 什么时候应该打日志 当你遇到问题的时候，只能通过debug功能来确定问题，你应该考虑打日志，良好的系统，是可以通过日志进行问题定为的。 当你碰到if…else 或者 switch这样的分支时，要在分支的首行打印日志，用来确定进入了哪个分支 经常以功能为核心进行开发，你应该在提交代码前，可以确定通过日志可以看到整个流程 基本格式 必须使用参数化信息的方式: logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol); 对于debug日志，必须判断是否为debug级别后，才进行使用: if (logger.isDebugEnabled()) { logger.debug("Processing trade with id: " +id + " symbol: " + symbol); } 不要进行字符串拼接,那样会产生很多String对象，占用空间，影响性能。 反例(不要这么做): logger.debug("Processing trade with id: " + id + " symbol: " + symbol); 使用[]进行参数变量隔离

为优化用户体验，使用 wx.getUserInfo 接口直接弹出授权框的开发方式将逐步不再支持。从2018年4月30日开始，小程序与小游戏的体验版、开发版调用 wx.getUserInfo 接口，将无法弹出授权询问框，默认调用失败。正式版暂不受影响。开发者可使用以下方式获取或展示用户信息： UnionID 机制说明 如果开发者拥有多个移动应用、网站应用、和公众帐号（包括小程序），可通过 UnionID 来区分用户的唯一性，因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号（包括小程序），用户的 UnionID 是唯一的。换句话说，同一用户，对同一个微信开放平台下的不同应用，unionid是相同的。所以我们有时候需要获取这个UnionID 这个图简单的可以看做三部分 1.微信小程序客户端 2.微信官方服务器 3.第三方服务器（这个可以看做是自己的） 具体步骤如下; 1. 客户端获得code，并将code传给第三方服务端 微信小程序端调用wx.login，获取登录凭证（code），并调用接口，将code发送到第三方客户端 2. 第三方服务端用code换session_key和openid 小程序端将code传给第三方服务器端，第三方服务器端调用接口，用code换取session_key和openid 3. 第三方服务端生成新的session（3rd_session）

每一个产品经理，应该都需要根据自己的职业生涯规划去搭建自己的知识能力体系。我把这些能力梳理总结为“两个闭环、三个心、四个力”，并对此展开了分析思考，与大家分享。 最近有个问题一直在我脑子里环绕，一名优秀的产品经理应该是什么样子的呢？ 我总结为：两个闭环、三个心、四个力，以下是我的一些思考。 （建议收藏） 两个闭环 产品闭环 要让用户通过使用我们的产品能够完成一些事情或任务，能够满足一定的用户需求，最终形成飞轮效应。 要做到产品闭环需要有上帝视角，需要对所有功能、各个端、不同角色、不同场景、业务逻辑都要考虑到； 比如做某一个功能，在通知层面，除了通过app的push推送，根据重要程度还可以加上服务号推送、小程序推送、SMS、EDM； 在业务层面需要更多的考虑用户不同场景、异常情况、用户心理等。 商业闭环 首先要清楚互联网通用的商业模式，广告流量变现、佣金分成、自营销售、会员增值服务、开放API、基于产品属性的盈利等。 然后就是清楚不同角色用户、公司之间的需求利益，达到一种平衡，结合公司情况形成一套完整的盈利模式； 平时多看商业类资讯提升商业敏感度，投资机构：IDG、红杉、深创投、晨兴、金沙江、创新工场、经纬中国、顺为、远望、YC中国等；财经视频：央视的对话、b站的半佛仙人、所长林超等。 三个心 产品心 “ 不想当将军的士兵不是好士兵。”对于产品，不想当产品大佬